Essentially, just wire up cancellation tokens and cancellation flags for `CompletionInstance` and make sure to return `CancellableResult::cancelled()` when cancellation is detected.
rdar://83391488
Previously, `SwiftASTManager` and `SlowRequestSimulator` maintained their own list of in-progress cancellation tokens. With code completion cancellation coming up, there would need to be yet another place to track in-progress requests, so let’s centralize it.
While at it, also support cancelling requests before they are scheduled, eliminating the need for a `sleep` in a test case.
The current implementaiton leaks tiny amounts of memory if a request is cancelled after if finishes. I think this is fine because it is a pretty nieche case and the leaked memory is pretty small (a `std::map` entry pointing to a `std::function` + `bool`). Alternatively, we could require the client to always dispose of the cancellation token manually.
The invocation of the code completion second pass should be implementation detail of `CompletionInstance`. Create a method on `CompletionInstance` that correctly invokes the second pass and just reutnrs the type context info results to the caller.
This refactors a bunch of code-completion methods around `performOperation` to return their results via a callback only instead of the current mixed approach of indicating failure via a return value, returning an error string as an inout parameter and success results via a callback. The new guarantee should be that the callback is always called exactly once on control flow graph.
Other than a support for passing the (currently unused) cancelled state through the different instance, there should be no functionality change.
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
- 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.
Previously, if the client requests no information from "edit" request,
the syntax info wasn't updated. But "expand placeholder" request
requires the up-to-date syntax info.
rdar://77665805
Adds a new 'key.retrieve_symbol_graph' option to the request. When set to 1 it
includes the JSON for a SymbolGraph containing a single node for the symbol at
the requested position.
This also extends the SymbolGraph library with a new entry point to get a graph
for a single symbol, and to additionally support type substitution to match the
existing CursorInfo behavior (e.g. so that when invoked on `first` in
`Array<Int>().first`, the type is given as `Int?` rather than `Element?`).
Resolves rdar://problem/70551509
In order to make range-shifting for semantic highlighting testable,
disable returning semantic information during an "open" request. This
has no real value anyway, since it only happens very rarely, and it
makes testing range shifting impossible to do deterministically.
rdar://problem/66386179
We would previously hide the protocol, its extensions and members, but the '_'
prefix really just means the protocol itself isn't intended for clients, rather
than its members.
This also adds support for 'fully_annotated_decl' entries in doc-info for
extensions to be consistent with every other decl, and removes the
'fully_annotated_generic_signature' entry we supplied as a fallback.
Also fixes several bugs with the synthesized extensions mechanism:
- The type sustitutions applied to the extension's requirements were computed
using the extension itself as the decl context rather than the extension's
nominal. The meant the extension's requirements themselves were assumed to
hold when determining the substitutions, so equality constraints were always
met. Because of this extension members were incorrectly merged with the base
nominal or its extensions despite having additional constraints.
- Types within the requirements weren't being transformed when printed (e.g.
'Self.Element' was printed rather than 'T') both in the interface output and
in the requirements list. We were also incorrectly printing requirements
that were already satisfied once the base type was subsituted in.
- If both the protocol extension and 'enabling' extension of the base nominal
that added the protocol conformance had conditional requirements, we were
only printing the protocol extension's requirements in the synthesized
extension.
- The USR and annotated decl output embedded in the 'key.doc.full_as_xml'
string for synthesized members were printed to match their original context, rather than
the synthesized one.
Resolves rdar://problem/57121937
Check if dependencies are modified since the last checking.
Dependencies:
- Other source files in the current module
- Dependent files collected by the dependency tracker
When:
- If the last dependency check was over N (defaults to 5) seconds ago
Invalidate if:
- The dependency file is missing
- The modification time of the dependecy is greater than the last check
- If the modification time is zero, compare the content using the file
system from the previous completion and the current completion
rdar://problem/62336432
To controls the lifetime of CompilerInstance within CompletionIntance.
- Prevent from using the same CompilerInstance from multiple completion
requests
- Separate the stacktrace between "fast" and "normal" completions
- Further code consolidation between various completion-like requests
- Introduce ide::CompletionInstance to manage CompilerInstance
- `CompletionInstance` vends the cached CompilerInstance when:
-- The compiler arguments (i.e. CompilerInvocation) has has not changed
-- The primary file is the same
-- The completion happens inside function bodies in both previous and
current completion
-- The interface hash of the primary file has not changed
- Otherwise, it vends a fresh CompilerInstance and cache it for the next
completion
rdar://problem/20787086
Structurally prevent a number of common anti-patterns involving generic
signatures by separating the interface into GenericSignature and the
implementation into GenericSignatureBase. In particular, this allows
the comparison operators to be deleted which forces callers to
canonicalize the signature or ask to compare pointers explicitly.
Propagates the VFS to the SemanticInfo that gets used when then
original editor.open is syntactic only.
Removes unnecessary filesystem arg (get filesystem from class field
instead).
Adds test for the VFS being propagated into the SemanticInfo.
Refactors test/SourceKit/CursorInfo/injected_vfs.swift to use
-print-raw-response for all its tests, for consistency.
The invocation options are not an appropriate place to put this state,
since it can change between requests. This moves it to the editor
document, allowing us to change the specific VFS instance without
causing a rebuild (unless the contents/timestamps for a dependency
change).
This has been an unnecessary code path for a long time now and should be removed particularly because it triggers wasteful `stat` calls.
rdar://51523161
