We treated enum case parameters the same way as function parameters and weren’t considering that they can be unlabeled. That caused us to insert eg. `_ ` in front of the case’s type, producing `case myCase(_ String)`, which is invalid. When we are inside an enum case parameter and the parameter label is empty, treat it the same as a function call, which will leave the label untouched if it isn’t modified and insert a label including a colon if a new label is introduced.
https://github.com/apple/sourcekit-lsp/issues/1228
I will remove the `syntactic-rename` refactoring action in a follow-up commit. Clients should always ask for rename ranges and perform the rename by themselves instead of asking for a renamed file.
"Function builders" are being renamed to "result builders". Add the
corresponding `@resultBuilder` attribute, with `@_functionBuilder` as
an alias for it, Update test cases to use @resultBuilder.
The backing property for 'foo' is now '_foo', and the projected value '$foo'.
This updates Indexing to report occurrences of foo within both $foo and
_foo occurrences (rather than just $foo - the old _foo).
FindRelatedIdents was similarlar updated, so it reports 'foo' ranges in both
_foo and $foo.
CursorInfo now reports the USR, documentation, and location of foo when invoked
occurrences of $foo or _foo, but now leaves the name, type, and annotated
declaration of _foo/$foo as is. Having the same USR ensures rename invoked on
any of them will still rename via foo. Reporting foo's documentation comment
instead is just to present something more useful to the user.
This patch achieves this by updating indexing to reporting the position of
`foo` in occurrences of `$foo` as an occurrence of the `foo` symbol, so
that renames initiated on occurrences of the `foo` symbol will also result
in occurrences of the `$foo` symbol being updated correctly. This also means
find-references on foo will show places where $foo is used.
Making rename work in the other direction (invoking rename on $foo upating foo
occurrences too) is still todo.
This fixes custom attribute syntax highlighting on parameters and functions
(where function builders can be applied). They weren't being walked in
the function position previously and were walked out of source order in the
parameter position.
It also fixes rename of the property wrapper and function builder type
names that can appear in custom attributes, as well as rename of property
wrapper constructors, that can appear after the type names, e.g.
`@Wrapper(initialValue: 10)`. The index now also records these constructor
occurrences, along with implicit occurrences whenever a constructor is
called via default value assignment, e.g. `@Wrapper var foo = 10`, so that
finding calls/references to the constructor includes these locations.
Resolves rdar://problem/49036613
Resolves rdar://problem/50073641
A label range of 0 length was being reported as the label of trailing closure
arguments, just before the opening '{'.
For the rename refactoring, this meant that if the corresponding parameter had
an external label (e.g. 'a') the occurrence would be treated as not matching the
expected symbol name, and so not be updated at all.
For the migrator, when renaming a function with an unlabelled closure for its
last parameter to have a label, it would incorrectly insert the new label in
front of the opening '{' on all of that function's callsites with trailing
closures.
Resolves rdar://problem/42162571
Some of the implicit decls generated for lazy vars have invalid source ranges.
For now, just always walk into implicit decls when looking for name locations.
Resolves rdar://problem/35255644.
Adds support for renaming subscripts with external names, e.g.
subscript(x y: Int), and introduces a noncollapsible parameter name range for
subscript parameters, since these shouldn't be collapsed with an argument label
of the same name as function parameter names are.
