This will allow us to run two different completion kinds and deliver results from both of them.
Also: Compute a unified type context for global lookup. Previously, we always used the expected type context of the last lookup. But really, we should be considering all possible types from all constraint system solutions when computing code completion results from the cache.
This hooks up call argument position completion to the typeCheckForCodeCompletion API to generate completions from all the solutions the constraint solver produces (even those requiring fixes), rather than relying on a single solution being applied to the AST (if any).
Co-authored-by: Nathan Hawes <nathan.john.hawes@gmail.com>
Computing the type relation for every item in the code completion cache is way to expensive (~4x slowdown for global completion that imports `SwiftUI`). Instead, compute a type’s supertypes (protocol conformances and superclasses) once and write their USRs to the cache. To compute a type relation we can then check if the contextual type is in the completion item’s supertypes.
This reduces the overhead of computing the type relations (again global completion that imports `SwiftUI`) to ~6% – measured by instructions executed.
Technically, we might miss some conversions like
- retroactive conformances inside another module (because we can’t cache them if that other module isn’t imported)
- complex generic conversions (just too complicated to model using USRs)
Because of this, we never report an `unrelated` type relation for global items but always default to `unknown`.
But I believe this change covers the most common cases and is a good tradeoff between accuracy and performance.
rdar://83846531
Computing the type relation for every item in the code completion cache is way to expensive (~4x slowdown for global completion that imports `SwiftUI`). Instead, compute a type’s supertypes (protocol conformances and superclasses) once and write their USRs to the cache. To compute a type relation we can then check if the contextual type is in the completion item’s supertypes.
This reduces the overhead of computing the type relations (again global completion that imports `SwiftUI`) to ~6% – measured by instructions executed.
Technically, we might miss some conversions like
- retroactive conformances inside another module (because we can’t cache them if that other module isn’t imported)
- complex generic conversions (just too complicated to model using USRs)
Because of this, we never report an `unrelated` type relation for global items but always default to `unknown`.
But I believe this change covers the most common cases and is a good tradeoff between accuracy and performance.
rdar://83846531
Filter name for completion item is always used. Also, for cached items,
they are used multiple times for filtering. So precomputing and caching
it improves performance.
rdar://84036006
Convert 'ContextFreeCodeCompletionResult' constructor overloads to
'create()' factory methods. This is the consistent interface with
'CodeCompletionString'. NFC
[CodeCompletion] Make ExpectedTypeContext a class with explicit getters/setters
This simplifies debugging because you can break when the possible types are set and you can also search for references to `setPossibleType` to figure out where the expected types are being set.
This allows makes the distinction between cachable and non-cachable properties cleaner and allows us to more easily compute contextual information (like type relations) for cached items later.
Previously the code completion methods just returned an `ArrayRef` that pointed into the result sink that contained the results but no effort was made to actually keep that that result sink alive, e.g. when transforming results in `transformAndForwardResults`.
Instead, return the `CodeCompletionResultSink` from the code compleiton methods now and adopt that sink from the inner results created in `transformAndForwardResults`.
Now that arguments are marked up with whether they have a default or
not, clients may not need the extra call (that has no default
arguments). Add an option to allow not adding this item.
Resolves rdar://85526214.
"add inits to toplevel" and "call pattern heuristics" are only used in
code completion. Move them from LangOptions to CodeCompletionContext so
that they don't affect compiler arguments.
* "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
The various keyword/recommended/etc fields were parsed and added to
completions, but never actually plumbed through SourceKit. Since they're
still unused and the implementation is not particularly lightweight,
just remove for now.
Resolves rdar://82464220
'available(..., deprecated: <version>)'. If the version is larger than the
current active version, the declaration is "soft deprecated". Emit a
relevant diagnostics for those items. If the version is equal to or
larger than '100000.0', it means the distant future without specifying
the version.
rdar://76122625
* Implement 'getDiagnosticSeverity()' and 'getDiagnosticMessage()' on
'CodeCompletionResult'
* Differentiate 'RedundantImportIndirect' from 'RedundantImport'
* Make non-Sendable check respects '-warn-concurrency'
rdar://76129658
* 'CodeCompletionContext' now has 'requiresSourceFileInfo()' flag
* When 'true', 'SourceFiles' is populated.
* 'SourceFiles' is a list of pairs of a known module source
file path and its up-to-date-ness
* Clients (i.e. 'CodeCompletionConsumer') can retrieve it from
'CodeCompletionContext' in 'handleResults'
* Each completion item now has 'SourceFilePath' property
* C-APIs to get those informations
`CodeCompletioString::getName()` was used only as the sorting keys in
`CodeCompletionContext::sortCompletionResults()` which is effectively
deprecated. There's no reason to check them in `swift-ide-test`. Instead,
check `printCodeCompletionResultFilterName()` that is actually used for
filtering.
* 'super' in a overriding decl is "common".
* type decl introducers (e.g. 'struct', 'enum') at top-level in library
files are "common"
* type decl introducers in 'protocol' are invalid, hence "rare"
* top-level only decl introducer (e.g. 'import', 'extension') are invalid
at non-top-level, hence "rare"
* nested types in function bodies are "rare"
* member only decls (e.g. 'subscript', 'deinit') are invalid in function
body, hence "rare"
* some modifiers (e.g. 'public', 'private', 'override') are invalid for
local decls, hence "rare"
rdar://77934651
