This brings up the ability to compute cursor info results using the completion-like type checking paradigm, which an reuse ASTContexts and doesn’t need to type check the entire file.
For now, the new implementation only supports cursor info on `ValueDecl`s (not on references) because they were easiest to implement. More cursor info kinds are coming soon.
At the moment, we only run the new implementation in a verification mode: It is only invoked in assert toolchains and when run, we check that the results are equivalent to the old implementation. Once more cursor info kinds are implemented and if the SourceKit stress tester doesn’t find any verification issues, we can enable the new implementation, falling back to the old implementation if the new one didn’t produce any results.
This way, each kind of `ResolvedCursorInfo` can define its own set of properties and it’s obvious which properties are used for which kind. Also switch to getters and setters because that makes it easier to search for usages of properties by looking at the call hierarchy of the getter / setter.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
IDE/Refactoring had dependencies to libswiftIndex, but libswiftIndex
also depends on libswiftIDE (SourceEntityWalker, etc.)
To break libswiftIndex <-> libswiftIDE dependency cycle, move
"refactoring" related files to a new library 'libswiftRefactoring'
rdar://101692282
This includes:
- bumping the SWIFT_SYMBOLGRAPH_FORMAT_MINOR version
- introduction of the "swift.extension" symbol and "extensionTo" relationship
- adding support for ExtensionDecl to the Symbol class
- adding a "typeKind" field to the symbol's extension mixin which indicates what kind
of symbol was extended
- intoduction of the -emit-extension-block-symbols flag, which enables the behavior
outlined below
- adaptions to SymbolGraphASTWalker that ensure a swift.extension symbol is emitted
for each extension to a type that does not exist in the local symbol graph
- adaptions to SymbolGraph and SymbolGraphASTWalker that ensure member and conformance
relationships are correctly associated with the swift.extension symbol instead of
the original type declaration's (extended nominal's) symbol where applicable
- adaptions to SymbolGraphASTWalker that ensure swift.extension symbols are connected
to their respective extended nominal's symbol using an extensionTo relationship
Testing:
- adds SymbolGraph tests that test behavior only relevant in
-emit-extension-block-symbols mode
- adapts some SymbolGraph tests to additionally test similar behavior for
extensions to external types in -emit-extension-block-symbols mode
- adapts some SymbolGraph tests to (additionally or exclusively) test the
behavior with -emit-extension-block-symbols mode enabled
Bugfixes:
- fixes a bug where some conformsTo relationships implicated by the conformances
declared on an extension to an external type were not emitted
(see test/SymbolGraph/Relationships/ConformsTo/Indirect.swift)
Further changes:
- documents the strategy for naming and associating children declared in extensions
to typealiases (see test/SymbolGraph/Relationships/MemberOf/Typealias.swift,
test/SymbolGraph/Symbols/Names.swift)
`typealias` is currently allowed to refer to a protocol without the `any` keyword. This breaks mangling the typealias type into a USR will crash because parameterized protocols are expected to be `any` types.
Implement a SourceKit-specific minimal workaround for that problem by not computing USRs for parameterized protocols.
rdar://98623438
This enables the ability to cancel requests, which aren’t code completion requests, again.
Previous crashes in SILGen are prevented by disabling cancellation during the SIL stages. Instead, we add dedicated cancellation checkpoints before and after SIL.
rdar://98390926
When a variable is re-declared using shorthand syntax (`[foo]` closure capture or `if let foo {`), the user doesn’t perceive this as a new variable declaration. Thus, we should return the original declaration as a secondary result.
rdar://91311033
rdar://75455650
Previously, the related idents request wouldn’t look through caputred variables like `[foo]`. Change the logic to consider the captured variable as well as the variable that’s implicitly declared for use inside the closure.
rdar://81628899
This currently doesn't check for inherited docs, ie. either the
imported declaration has docs or it doesn't. There's also a few odd
cases with mixed doc types and when each line is prefixed with '*', but
it's good enough for an initial implementation.
Moves UTF8 sanitisation out of ASTPrinter.h and into Unicode.h so that
it can be used here as well.
Resolves rdar://91388603.
Only declarations in the same module as synthesized extension's target
are placed within a synthesized extension. We should thus not add
"::SYNTHESIZED::" to the USR if the given declaration is in a different
and.
As an example, `Foundation` adds a method `components(separatedBy:)` to
`String` through an extension on `StringProtocol`. But since it is
within `Foundation` and not `Swift` it will *not* be in a synthesized
extension of `String` or `StringProtocol`. So it should not have
"::SYNTHESIZED::" added and should also not being in the `String` group.
Resolves rdar://71355632.
Mark implicit declarations with a `synthesized` field, since while we
still want them to have a cursor info result (eg. for their USR to find
possible overrides), it's likely that clients will want to treat them
differently to results that have a real location in source.
An alternative could be to remove the location entirely, but:
- the module name would also have to be removed to prevent wasted
lookups in the generated interface
- having the location could still be useful as the location that
caused the synthesized declaration (though at the moment only
synthesized initializers have a location)
Resolves rdar://84990655
To simplify clients, have the cursorinfo result be consistent whether
requesting a symbol within the current module or not, ie. do not skip
adding the module name.
Resolves rdar://77003299
Currently, SourceKit always implicitly sends diagnostics to the client after every edit. This doesn’t match our new cancellation story because diagnostics retrieval is no request and thus can’t be cancelled.
Instead, diagnostics retrieval should be a standalone request, which returns a cancellation token like every other request and which can thus also be cancelled as such.
The indented transition path here is to change all open and edit requests to be syntactic only. When diagnostics are needed, the new diagnostics request should be used.
rdar://83391522
The key changes here are
- To keep track of cancellation tokens for all `ScheduledConsumer`s in `SwiftASTManager`
- Generate unique request handles for all incoming requests (`create_request_handle `), use these request handles as cancellation tokens and return them from the `sourcekitd_send_request` methods
- Implement cancellation with `sourcekitd_cancel_request` as the entry point and `SwiftASTManager::cancelASTConsumer` as the termination point
Everything else is just plumbing the cancellation token through the various abstraction layers.
rdar://83391505
* "description" for override completion is now annotatable
* "description" doesn't include attributes and decl introducer, but it
includes generic paramters, effects specifiers, result type clause,
and generic where clauses
* "name" now only include the name and the parameter names
* "sourcetext" should be the same
rdar://63835352
When a range is a single expression/statement/decl or part of
expression, also return cursor based refactorings for the start of the
range.
This is a stop gap until the available refactorings are properly fixed
to be more lenient in general - the current fix is a little odd as eg.
if all of `foo.bar()` is selected, rename will be returned as an
available refactoring for `foo`. Still an improvement over completely
missing cursor based refactorings, however.
Resolves rdar://82060063
For more fine grained annoations. For now, it's handled as the same as
'Keyword' name kind.
Fix an issue where 'extension' wasn't marked as "keyword".
Also, move 'static' priting out of 'SkipIntroducerKeywords' guard
because 'static' is not an declaration introducer.
- Add VariableTypeCollector
This new SourceEntityWalker collects types from variable declarations.
- Add SwiftLangSupport::collectVariableTypes
- Implement CollectVariableType request
- Provide information about explicit types in CollectVarType
- Fix HasExplicitType in VariableTypeArray
- Fix typo
- Implement ranged CollectVariableTypes requests
- Use offset/length params for CollectVariableType in sourcekitd-test
- Address a bunch of PR suggestions
- Remove CanonicalType from VariableTypeCollector
This turned out not to be needed (for now).
- Improve doc comment on VariableTypeCollector::getTypeOffsets
- Remove unused CanonicalTy variable
- Remove out-of-date comment
- Run clang-format on the CollectVariableType implementation
- Fix some minor style issues
- Use emplace_back while collecting variable infos
- Pass CollectVariableType range to VariableTypeCollector
- Use capitalized variable names in VariableTypeArray
...as recommended by the LLVM coding standards
- Use PrintOptions for type printing in VariableTypeCollector
- Return void for collectVariableType
This seems to be cleaner stylistically.
- Avoid visiting subranges of invalid range in VariableTypeCollector
- Use std::string for type buffer in VariableTypeCollectorASTConsumer
- Use plural for PrintedType in VariableTypeArray
- Remove unused fields in VariableTypeArrayBuilder
- Add suggested doc comments to VariableTypeArray
- Remove unused VariableTypeInfo.TypeLength
- Fix typo of ostream in VariableTypeCollectorASTConsumer
- Fix typo
- Document Offset and Length semantics in collectVariableTypes
During a cursor info request, the resolved offset was mapped to line and
column using the buffer inside `SwiftDocumentSyntaxInfo`.
However, prior to 54683ca607,
`editorReplaceText` was not updating the syntax info. This meant that
snapshots would be more up to date than the buffer in the syntax info,
allowing for the possibility of an invalid offset.
While 54683ca607 would also fix this,
snapshots actually have a `getLineAndColumn` anyway. Use that instead of
grabbing the buffer from syntax info.
Resolves rdar://78161348.
If the compiler arguments have errors in them (e.g. because a file with the same name is used twice), we can often still fulfill SourceKit requests because the compiler argument errors are only relevant for later stages of the compilation process.
Instead of bailing out early, do a best effor retrieving the compiler arguments that are valid and ignoring the errors.
Fixes rdar://77618144
Have SourceKit return locations for symbols outside of the current
module as well. Callsites of location and comment information should
explicitly disable retrieving serialized information where performance
is a concern.
Resolves rdar://75582627
.swiftsourceinfo files contain the serialized location for declarations.
Use this when outputting locations in cursor info so that clients need
not perform an extra index lookup for external modules.
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.
Cursor info for a constructor would previously give the cursor info for
the containing type only. It now also adds cursor info for the
constructor itself in a "secondary_symbols" field.
Refactor `passCursorInfoForDecl` to use a single allocator rather than
keeping track of positions in a buffer and assigning everything at the
end of the function.
Refactor the various available refactoring gathering functions to take a
SmallVectorImpl and to not copy strings where they don't need to.
Resolves rdar://75385556
Adds two new fields to the cursor info response:
1. is_dynamic: whether a call is dynamic
2. receivers: receivers of the call (USRs)
Users of the CursorInfo request can use "is_dynamic" to decide whether
to lookup overrides or not, and then the "receivers" as the starting
point of the lookup.
Resolves rdar://75385900
