Use the higher level APIs on SourceManager that handle locations in
parent vs child buffers. This then allows us to fix `walkToDeclPre`
such that we don't set the found DeclContext unless the location is
actually within that decl (here the location may well be in a
separate buffer as we may have a replaced function body).
The logic here for completion wasn't actually
helping things since it would result in adding the
var overload to the system, which would result
in an ErrorType binding. We could turn the ErrorType
into a placeholder when resolving the overload,
but the simpler solution is to just allow CSGen
to turn the reference into a PlaceholderType. This
matches what we do for regular solving, and fixes
a crash with an IUO completion.
rdar://89369091
On Windows, we run into the following situation when running SourceKit-LSP tests:
- The SDK is located at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk` with `S:` being a substitution drive
- We find `Swift.swiftmodule` at `S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\windows\Swift.swiftmodule`
- Now, to check if `Swift.swiftmodule` is a system module, we take the realpath of the SDK, which resolves the substitution drive an results in something like `C:\Users\alex\src\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk`
- Since we don’t take the realpath of `Swift.swiftmodule`, we will assume that it’s not in the SDK, because the SDK’s path is on `C:` while `Swift.swiftmodule` lives on `S:`
To fix this, we also need to check if a module’s real path is inside the SDK.
Fixesswiftlang/sourcekit-lsp#1770
rdar://138210224
Modules defined within the SDK are considered
non-user modules, extend this to any module found
within the parent platform directory if there is
one. This ensures we include modules such as
XCTest and Testing.
rdar://131854240
Add a cached request to perform pattern resolution.
This is needed to prevent the constraint system
from resolving the same pattern multiple times
along different solver paths, which could result
in creating different pattern nodes for each path.
Once pattern resolution is moved to pre-checking
we ought to be able to make this uncached.
rdar://128661960
Computing capture information requires a type checked AST, which we don’t have during code completion. To fix an assertion failure, don’t look for a captured `isolated` parameter while computing a closure’s actor isolation during code completion.
rdar://126923558
To compute the expected type of a call pattern (which is the return type of the function if that call pattern is being used), we called `getTypeForCompletion` for the entire call, in the same way that we do for the code completion token. However, this pattern does not generally work. For the code completion token it worked because the code completion expression doesn’t have an inherent type and it inherits the type solely from its context. Calls, however, have an inherent return type and that type gets assigned as the `typeForCompletion`.
Implement targeted checks for the two most common cases where an expected type exists: If the call that we suggest call patterns for is itself an argument to another function or if it is used in a place that has a contextual type in the constraint system (eg. a variable binding or a `return` statement). This means that we no longer return `Convertible` for call patterns in some more complex scenarios. But given that this information was computed based on incorrect results and that in those cases all call patterns had a `Convertible` type relation, I think that’s acceptable. Fixing this would require recording more information in the constraints system, which is out-of-scope for now.
When completing in cases like `bar(arg: foo(|, option: 1)`, we don’t know if `option` belongs to the call to `foo` or `bar`. Be defensive and also suggest the signature.
This removes the distinction between argument completions and postfix expr paren completions, which was meaningless since solver-based completion.
It then determines whether to suggest the entire function call pattern (with all argument labels) or only a single argument based on whether there are any existing arguments in the call.
For this to work properly, we need to improve parser recovery a little bit so that it parsers arguments after the code completion token properly.
This should make call pattern heuristics obsolete.
rdar://84809503
`getLoc` does not necesarrily return the start location of the location (e.g. for `a.b().c()` it returns the location of `c` because that’s the location of the call). But we used the location from `getLoc` as the start location of the synthesized `buildExpression` call. In the added test case, this means that the `buildExpression` call only contained `everlay() {}` and not the code completion token. We thus infered that we could skip it the entire `MyStack {}.pnTabGesture {}.everlay() {}` call for code completion, which isn’t correct.
rdar://120798355
When completing, we call `getExistentialType` on the contextual type to get a nice and concise description of the contextual parameter’s type that doesn’t contain archetypes and which we can also serialize into a USR so we are able to calculate type relations for code completion results from the code completion cache.
When completing in a position that has a contextual type which only constrains one of two primary associated protocol types, this fails because `getExistentialType` (which calls `getDependentUpperBounds`) tries to form a `ParameterizedProtocolType`, which fails since not all primary associated types have been constrained.
AFAICT the fix here is to just fall back to the default behavior of returning the plain protocol type instead of `abort`ing.
rdar://108835466
It's possible for out-of-scope type variable to be the type of
declaration if such declaration is recursively referenced in
the body of a closure located in its initializer expression.
In such cases type of the variable declaration cannot be connected
to the closure because its not known in advance (determined by the
initializer itself).
Resolves: https://github.com/apple/swift/issues/63455
When computing type relations of code completion items with respect to the context they are used in, we add a `ConstraintKind::Conversion` constraint with an empty constraint locator. This currently crashes in `hasPreconcurrencyCallee`, but actually having a null anchor doesn’t produce any issues.
A call to `SanitizeExpr` has been incorrectly removed from
`typeCheckForCodeCompletion` by refactoring to use `ASTNode`.
It is still required because fallback calls could have partially
type-checked AST.
Resolves: https://github.com/apple/swift/issues/59315
Resolves: rdar://94619388
The following issues no longer reproduce on `main` and had reduced reproducers. Add them to the test suite.
- SR-12977
- SR-14691
- SR-15113
- rdar://63063279
- rdar://64227741
- rdar://69813796
- rdar://85609548
You would think that superclass + conformances form a DAG. You are wrong!
We can achieve a circular supertype hierarcy with
```swift
protocol Proto : Class {}
class Class : Proto {}
```
USRBasedType is not set up for this. Serialization of code completion results from global modules can't handle cycles in the supertype hierarchy
because it writes the DAG leaf to root(s) and needs to know the type offsets. To get consistent results independent of where we start
constructing USRBasedTypes, ignore superclasses of protocols. If we kept track of already visited types, we would get different results depending on
whether we start constructing the USRBasedType hierarchy from Proto or Class.
Ignoring superclasses of protocols is safe to do because USRBasedType is an under-approximation anyway.
rdar://91765262
I think that preferring identical over convertible makes sense in e.g. C++ where we have implicit user-defined type conversions but since we don’t have them in Swift, I think the distinction doesn’t make too much sense, because if we have a `func foo(x: Int?)`, want don’t really want to prioritize variables of type `Int?` over `Int` Similarly if we have `func foo(x: View)`, we don’t want to prioritize a variable of type `View` over e.g. `Text`.
rdar://91349364
