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>
Instead of setting the code completion position when parsing the if-statement, which doesn’t create a `CodeCompletionExpr`, parse it as a new top-level expression.
As far as test-cases are concerned, this removes the “RareKeyword” flair from top-level completions in the modified test case. This makes sense IMO.
Previously we didn't give any type relations to cached imported symbols.
So there was a hack to add the type matching nominal type with type
relation manually, which caused duplicated candiates, one from the
cache, one added manually.
Now that we have type relations for cached symbols so we don't need this
hack anymore.
rdar://90136020
This ensures that opened archetypes always inherit any outer generic parameters from the context in which they reside. This matters because class bounds may bind generic parameters from these outer contexts, and without the outer context you can wind up with ill-formed generic environments like
<τ_0_0, where τ_0_0 : C<T>, τ_0_0 : P>
Where T is otherwise unbound because there is no entry for it among the generic parameters of the environment's associated generic signature.
When parameter is added by addSimpleNamedParameter(), the type name
doesn't exist. Instead of printing empty strings, use short version of
editor placeholders.
rdar://83904268
Previously, for every type, we were reconstructing its entire supertype hierarchy as USRBasedTypes before checking the already computed USRBasedTypes. This lead to unneccary duplicated work.
Sendable conformances are lazily synthesized as they are needed by the compiler. Depending on whether we checked whether a type conforms to Sendable before constructing the USRBasedType, we get different results for its conformance, causing assertion failures. For now, always ignore the Sendable conformance. We need to come up with a better solution for this problem in the future.
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
Previously, for every type, we were reconstructing its entire supertype hierarchy as USRBasedTypes before checking the already computed USRBasedTypes. This lead to unneccary duplicated work.
Sendable conformances are lazily synthesized as they are needed by the compiler. Depending on whether we checked whether a type conforms to Sendable before constructing the USRBasedType, we get different results for its conformance, causing assertion failures. For now, always ignore the Sendable conformance. We need to come up with a better solution for this problem in the future.
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
