Extensions redeclare all generic parameters of their extended type to add their additional restrictions. There are two issues with this model for indexing:
- The generic paramter declarations of the extension are implicit so we wouldn't report them in the index. Any usage of the generic param in the extension references this implicit declaration so we don't include it in the index either.
- The implicit re-declarations have their own USRs so any usage of a generic parameter inside an extension would use a different USR than declaration of the param in the extended type.
To fix these issues, we replace the reference to the implicit generic parameter defined in the extension by a reference to the generic paramter defined in the extended type.
Various uses of `getPresumedLineAndColumnForLoc` were likely added when
that function was the very misleading name `getLineAndColumn`. Change
these to use `getLineAndColumnForBuffer` instead where appropriate, ie.
we want the underlying file rather than the location to display to the
user.
There were also some cases where the buffer identifier had been swapped
to use the display name instead, under the assumption that the presumed
location was needed. Updated those as well.
SingleRawComment: Lines are only used when merging comments, where the
original location is fine to use.
Index: Doesn't store the file set in #sourceLocation, so using the
presumed line would end up pointing to a location that makes no sense.
Editor functionality: Formatting and refactoring are on the current
file. Using the presumed location would result in incorrect
replacements.
The cursor info request also needs to output whether a call is "dynamic"
or not, move the functions related to this out of Index.cpp and into
IDE/Utils.cpp.
Also cleanup the `TrailingExpr` handling in `CursorInfoResolver` - it
only needs the first expression.
`class` functions can be overridden in subclasses but did not have the
`Dynamic` role added to their calls. Also add the `ReceivedBy` relation
in the simple case of an open archetype, leaving the more complicated
general generic case for now.
The indexer was looking into “empty” extensions to public types,
triggering computing their USR which could fail at
deserializing the implementation-only imported types. As a solution,
don’t index extensions with nothing to index in system modules.
rdar://70225906
To help consolidate our various types describing imports, this commit moves the following types and methods to Import.h:
* ImplicitImports
* ImplicitStdlibKind
* ImplicitImportInfo
* ModuleDecl::ImportedModule
* ModuleDecl::OrderImportedModules (as ImportedModule::Order)
* ModuleDecl::removeDuplicateImports() (as ImportedModule::removeDuplicates())
* SourceFile::ImportFlags
* SourceFile::ImportOptions
* SourceFile::ImportedModuleDesc
This commit is large and intentionally kept mechanical—nothing interesting to see here.
This makes it easier to specify OptionSet arguments.
Also modify appropriate uses of ModuleDecl::ImportFilter to take
advantage of the new constructor.
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
`SynthesizedFileUnit` is a container for synthesized declarations. Currently, it
only supports module-level declarations.
It is used by the SIL differentiation transform, which generates implicit struct
and enum declarations.
The fake module names we create when indexing a Swift module divided into
'groups' (e.g. the stdlib) don't have to be valid Swift module names, but we
were manipulating them to be so. E.g. the stdlib "Lazy Views" group, became
"Lazy_Views". This name is displayed in some editors verbatim, and is also
used as input to some sourcekitd APIs (e.g. editor.open.interface) that only
work if the original group name is passed, rather than the processed one.
This patch stops mapping invalid module name characters like ' ' and '-' to '_'
so the original group name remains.
Resolves rdar://problem/57270811
Several tests related to indexing system modules were taking a considerable
amount of time (100+ seconds in the worst case) indexing the standard library.
This adds a frontend option to skip it and updates those tests to pass it.
Two more pair of string conversion fixes. With this, I was able to build
swift master-next on Ubuntu 16.04 (didn't try anything downstream of
swift, and not sure if the tests pass).
* Reference is marked "explicit", which may be unexpected - the reason
is that the *call* is explicit, so we want to find it with e.g. rename,
or looking up callers, even though the identifier callAsFunction is
implicit. This matches the behaviour of initializers.
* The source location is the same as the base name (e.g. in `add3(5)`,
it would be at `add3`), which matches the behaviour of initializers.
rdar://problem/60327632
When a “separately imported overlay” is added to a SourceFile, two things happen:
1. The direct import of the underlying module is removed from getImports*() by default. It is only visible if the caller passes ImportFilterKind:: ShadowedBySeparateOverlay. This means that non-module-scoped lookups will search _OverlayModule before searching its re-export UnderlyingModule, allowing it to shadow underlying declarations.
2. When you ask for lookupInModule() to look in the underlying module in that source file, it looks in the overlays instead. This means that UnderlyingModule.foo() can find declarations in _OverlayModule.
Replaces `ComponentIdentTypeRepr::getIdentifier()` and `getIdLoc()` with `getNameRef()` and `getNameLoc()`, which use `DeclName` and `DeclNameRef` respectively.
When Decl::getLoc() is called upon a serialized AST and the
serialized source location is available, we lazily open the
external buffer and return a valid SourceLoc instance pointing
into the buffer.
