For a case like:
```
public class C<T> {}
public class D {}
extension C where T : D {
public func foo() {}
}
```
We would indadvertedly drop the extension for `C`
in the doc info, as the superclass constraint would
fail the `isBindableToSuperclassOf` check.
Instead, map the subject type of the constraint
into the context and check if it could be bound to
the superclass. In the example above, this is
trivially true, but for cases where we're mirroring
a protocol extension onto the type, this will
disregard those that don't fulfil the requirements.
Resolves rdar://76868074
According to Pavel, we want to eliminate allowing unresolved variables as much as possible. Removing this flag doesn’t break any test cases (at least not in a meaningful way) and fixes a crasher, so it seems reasonable to remove it.
Fixes rdar://76686564
1. Removes gating on -enable-experimental-concurrency.
2. Updates eff. prop tests to remove experimental flag,
and also adjusts some tests slightly to avoid things
that are still behind that flag.
For example:
class Base {
init(_: Int) {}
convenience init(_: Int) { self.init() }
}
class Derived: Base {
convenience init(sub: Int) { self.init(sub) }
}
Derived(#^HERE^#
In this case, the call is type checked to 'Base.init(_:)' and 'Derived'
is wrapped with 'MetatypeConversionExpr' with type 'Base.Type'. We need
to look through it to get the 'TypeExpr' with 'Derived.Type'.
rdar://74233797
The triple name aarch64_32 does not actually name a valid platform. The
actual platform (and valid triple arch string, confusingly enough) is
arm64_32. Remap between the two to correct for this difference.
rdar://77281393
In the following test case, we are crashing while building the generic signature of `someGenericFunc`, potentially invoked on `model` in line 11.
```swift
struct MyBinding<BindingOuter> {
func someGenericFunc<BindingInner>(x: BindingInner) {}
}
struct MyTextField<TextFieldOuter> {
init<TextFieldInner>(text: MyBinding<TextFieldInner>) {}
}
struct EncodedView {
func foo(model: MyBinding<String>) {
let _ = MyTextField<String>(text: model)
}
}
```
Because we know that `model` has type `MyBinding<TextFieldInner>`, we substitute the `BindingOuter` generic parameter by `TextFieldInner`. Thus, `someGenericFunc` has the signature `<TextFieldInner /* substitutes BindingOuter */, BindingInner>`. `TextFieldInner` and `BindingOuter` both have `depth = 1`, `index = 0`. Thus the verification in `GenericSignatureBuilder` is failing.
After discussion with Slava, the root issue appears to be that we shouldn’t be calling `subst` on a `GenericFunctionType` at all. Instead we should be using `substGenericArgs` which doesn’t attempt to rebuild a generic signature, but instead builds a non-generic function type.
--------------------------------------------------------------------------------
We slightly regress in code completion results by showing two `collidingGeneric` twice in the following case.
```swift
protocol P1 {
func collidingGeneric<T>(x: T)
}
protocol P2 {
func collidingGeneric<T>(x: T)
}
class C : P1, P2 {
#^COMPLETE^#
}
```
Previously, we were representing the type of `collidingGeneric` by a generic function type with generic param `T` that doesn’t have any restrictions. Since we are now using `substGenericArgs` instead of `subst`, we receive a non-generic function type that represents `T` as an archetype. And since that archetype is different for the two function signatures, we show the result twice in code completion.
One could also argue that showing the result twice is intended (or at least acceptable) behaviour since, the two protocol may name their generic params differently. E.g. in
```swift
protocol P1 {
func collidingGeneric<S>(x: S)
}
protocol P2 {
func collidingGeneric<T>(x: T)
}
class C : P1, P2 {
#^COMPLETE^#
}
```
we might be expected to show the following two results
```
func collidingGeneric<S>(x: S)
func collidingGeneric<T>(x: T)
```
Resolves rdar://76711477 [SR-14495]
Not-filtering solutions causes unacceptable slownesses in some cases.
For now, filter solutions as normal typechecking does to restore the
performance.
rdar://76714968
Consider the following example.
```swift
protocol FontStyle {}
struct FontStyleOne: FontStyle {}
extension FontStyle where Self == FontStyleOne {
static var one: FontStyleOne { FontStyleOne() }
}
func foo<T: FontStyle>(x: T) {}
func case1() {
foo(x: .#^COMPLETE^#)
}
```
With SE-0299 accepted, we should be suggesting `.one`.
For that, we need to consider the extension applied when performing the unresolved dot code completion with a primary archetype that conforms to `FontStyle`.
However, in the following case, which performs an unresolved dot completion on the same base type, we don't want to suggest `.one` because that would require `T == FontStyleOne`, which we can’t assume.
```swift
func case2<T: FontStyle>(x: T) {
x.#^COMPLETE_2^#
}
```
Since the constraint system cannot tell us how it came up with the archetype, we need to apply a heuristic to differentiate between the two cases.
What seems to work fine in most cases, is to determine if `T` referes to a generic parameter that is visible from the decl context we are completing in (i.e. the decl context we are completing in is a child context of the context that `T` is declared in). If it is not, then `T` cannot be the type of a variable we are completing on. Thus, we are in the first case and we should consider all extensions of `FontStyle` because we can further specialize `T` by picking a more concrete type.
Otherwise `T` may be the type of a variable we are completing on and we should be conservative and only suggest those extensions whose requirements are fulfilled by `T`.
Since this is just a heuristic, there are some corner cases, where we aren’t suggesting constrainted extensions although we should. For example, in the following example the call to `testRecursive` doesn’t use `T` and we should thus suggest `one`. But by the rules described above we detect that `T` is accessible at the call and thus don’t apply extension whose requirements aren’t satisfied.
```swift
func testRecursive<T: FontStyle>(_ style: T) {
testRecursive(.#^COMPLETE_RECURSIVE_GENERIC^#)
}
```
Similar completion issues also occurred without SE-0299 in more complicated, generic scenarios.
Resolves rdar://74958497 and SR-12973
For a function and call like
```swift
func test(_: Foo..., yArg: Baz) {}
test(.bar, #^COMPLETE^#)
```
the parser matches the code completion token to the `yArg` with a missing label, because this way all parameters are provided. However, because of this we don’t suggest any variables that could belong the the previous vararg list.
To fix this, if we encounter such a situation (argument without label after vararg), manually adjust the code completion token’s position in params to belong to the vararg list.
Fixes rdar://76977325 [SR-14515]
For various reasons, it can be useful/interesting to create builds of
Swift that minimize dependencies. Let's try to keep that working as long
as we can.
At the moment, if there is an error in the `switch` statement expression or if the `{` is missing, we return `nullptr` from `parseStmtSwitch`, but we consume tokens while trying to parse the `switch` statement. This causes the AST to not contain any nodes for the tokens that were consumed while trying to parse the `switch` statement.
While this doesn’t cause any issues during compilation (compiling fails anyway so not having the `switch` statement in the AST is not a problem) this causes issues when trying to complete inside an expression that was consumed while trying to parse the `switch` statement but doesn’t have a representation in the AST. The solver-based completion approach can’t find the expression that contains the completion token (because it’s not part of the AST) and thus return empty results.
To fix this, make sure we are always creating a `SwitchStmt` when consuming tokens for it.
Previously, one could always assume that a `SwitchStmt` had a valid `LBraceLoc` and `RBraceLoc`. This is no longer the case because of the recovery. In order to form the `SwitchStmt`’s `SourceRange`, I needed to add a `EndLoc` property to `SwitchStmt` that keeps track of the last token in the `SwitchStmt`. Theoretically we should be able to compute this location by traversing the right brace, case stmts, subject expression, … in reverse order until we find something that’s not missing. But if the `SubjectExpr` is an `ErrorExpr`, representing a missing expression, it might have a source range that points to one after the last token in the statement (this is due to the way the `ErrorExpr` is being constructed), therefore returning an invalid range. So overall I thought it was easier and safer to add another property.
Fixes rdar://76688441 [SR-14490]
Since 865e80f9c4 we are keeping track of internal closure labels in the closure’s type. With this change, wer are also serializing them to the swiftmodules.
Furthermore, this change adjusts the printing behaviour to print the parameter labels in the swiftinterfaces.
Resolves rdar://63633158
Due to https://github.com/apple/swift/pull/36552, parsing the code completion token as a type inside a generic parameter list no longer fails. Instead, it consumes the code completion token as a type identifier. However, since `parseExprIdentifer` does not return a `ParserStatus`, the information whether a code completion token was consumed gets lost, causing `setCodeCompletionDelayedDeclState` to not be called and thus no code completion results show up.
To resolve this, make `parseExprIdentifier` return its `ParserStatus` through a `ParserResult`.
Fixes rdar://76335452 [SR-14432]
The last token in a case stmt can be a string literal token, which can *contain* its interpolation segments. If one of these interpolation segments is the reference point, we'd return false from `isReferencePointInRange` because the string literal token's start location is before the interpolation token. To fix this, adjust the range we are checking to range until the end of the string interpolation token.
Fixes rdar://76330416 [SR-14455]
The actual fix is to perform qualified lookup on a TypeExpr in `collectPossibleCalleesForApply`.
This changes the behaviour of some test cases in `complete_multiple_trailingclosure.swift`, which now provide argument labels. To make the choices suggested less verbose, I refined the parameter matching to only match trailing closures to parameters of function types.
In `INIT_FALLBACK_1` we technically shouldn't be suggesting `arg3` based on the matched argument types (the closure returns `Int` and the constructor with `arg3` requires the closure to return `String`), but AFAICT we aren't doing type-checking at this stage, so there's no way to rule it out.
Currently, if the code completion token is after a label that refers to a vararg, it is part of that VarargExpansionExpr, so we don’t suggest the subsequent parameter’s label.
Add special handling to detect this situation and suggest the parameter label.
Fixes rdar://76355192
