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
These files were using clang::SourceManager with only a forward declaration.
Most likely another header was previously including the SourceManager header so
that these files got the header included transitively.
SwiftSourceInfo files provide source location information for decls coming from
loaded modules. For most IDE use cases it either has an undesirable impact on
performance with no benefit (code completion), results in stale locations being
used instead of more up-to-date indexer locations (cursor info), or has no
observable effect (live diagnostics, which are filtered to just those with a
location in the primary file).
For non-IDE clients of SourceKit though, cursor info providing declaration
locations for symbols from other modules is useful, so add a global
configuration option (and a new request to set it) to control whether
.swiftsourceinfo files are loaded or not based on use case (they are loaded by
default).
TypeCheckPattern used to splat the interface type into this, and
different parts of the compiler would check one or the other. There is
now one source of truth: The interface type. The type repr is now just
a signal that the user has written an explicit type annotation on
a parameter. For variables, we will eventually be able to just grab
this information from the parent pattern.
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 is the final piece to get rename and findRelatedIdents to include all foo
and $foo occurrences, for example, in the set of occurrences to be renamed or
shown, regardless of whether they were initiated on a foo or $foo.
Resolves rdar://problem/51695783.
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
Ensure the various entity walkers handle the implicit subscript
reference correctly (usually by ignoring it) and fall through to the
underlying declarations.
rdar://49028895
When building the implicit subscript expression, set the "implicit" bit
correctly and pass it through in the indexer so that we get implicit
refernces to the subscript. This would be useful for e.g. searching for
all uses of the dynamic subscript.
When CursorInfo finds a reference to a VarDecl that's implicit but has a parent
VarDecl (according to VarDecl::getParentVarDecl), act as if we found the parent
instead.
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
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
For example:
class Foo<T> {
let test: Bool = false
let items: [Int] = []
func foo() {
if test {} // crashes on test
for i in items {} // crashes on items
}
}
We were picking up the incorrect containing type (Bool rather than Foo<T>).
Resolves rdar://problem/36871908.
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.
NameMatcher checked if a StringLiteralExpr was a string segment in an
interpolated string by checking if the parent expression was an
InterpolatedStringLiteralExpr. That's only true pre-type-checking, and unlike
global rename, local rename uses the type-checked AST.
