"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.
This change makes us treat it exactly as we do 'init'. We don't allow renaming the base name,
and don't fail if the basename doesn't match for calls.
Also:
- explicit init calls/references like `MyType.init(42)` are now reported with
'init' as a keywordBase range, rather than nothing.
- cursor info no longer reports rename as available on init/callAsFunction
calls without arguments, as there's nothing to rename in that case.
- Improved detection of when a referenced function is a call (rather than
reference) across syntactic rename, cursor-info, and indexing.
Resolves rdar://problem/60340429
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.
Make sure they handle the case when a property wrapper type's constructor is
called with the first argument coming from the var initializer, and the rest
from the custom attribute's argument.
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
We weren't renaming all occurrences of 'x' in the cases like the below:
case .first(let x), .second(let x):
print("foo \(x)")
fallthrough
case .third(let x):
print("bar \(x)")
We would previously only rename occurrences within the case statement the query
was made in (ignoring fallthroughs) and for cases with multiple patterns (as in
the first case above) we would only rename the occurrence in the first pattern.
For context, String, Nil, and Bool already behave this way.
Note: Before it used to construct (call, ... (integer_literal)), and the
call would be made explicit / implicit based on if you did eg: Int(3) or
just 3. This however did not translate to the new world so this PR adds
a IsExplicitConversion bit to NumberLiteralExpr. Some side results of
all this are that some warnings changed a little and some instructions are
emitted in a different order.
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
Set local discriminator for all local `VarDecl`s. Otherwise, they cannot
be discriminated with USRs. This change is needed for rename refactoring which
uses USR for discrimiating variable names.
https://bugs.swift.org/browse/SR-7205,
rdar://problem/34701880
Otherwise, it's never initialized. This doesn't affect normal compilation
because it doensn't reach only-user SILGen due to typecheck error. However,
IDE refactoring uses this regardless of the error.
rdar://problem/33972653
This is immensely useful when working on generic code, where the signatures
of (many) functions are all that is required, and removing the bodies makes
things compile faster, allows tools like creduce to work better and results in
less noise in a debugger.
Unfortunately the design of refactoring means this currently only works on a
single top-level decl, or multiple decls inside a type.
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
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.
