Two paths missed setting up overlays:
- `CompletionInstance` when checking files from dependencies
- `SwiftASTManager` when reading in files that it would later replace
all inputs with
(1) would cause the AST context not to be re-used, even though nothing
had changed. (2) caused all non-completion functionality to fail for any
symbols within files only specified by the overlay.
Resolves rdar://85508213.
This eliminates a source of bugs if subclasses of `TypeCheckCompletionCallback` forget to call the superclass’s implementation of `sawSolution` from their overridden method.
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.
