* [ConstraintSystem] NFC: Rename `openOpaqueTypeRec` and make `openOpaqueType` private for individual types
* [ConstraintSystem] Require a contextual purpose for `openOpaqueType(Type, ...)`
Some of the contexts require special handling e.g. return type of a function
can only open directly declared opaque result type(s), this would be
implemented in a follow-up commit.
* [ConstraintSystem] Open only directly declared opaque types related to return statements
Re-establish a check which would only open opaque types directly
declared in the return type of a function/accessor declaration,
otherwise constraint system would end up with type variables it
has no context for if the type had generic parameters.
Resolves: rdar://81531010
wrapped parameters and wrapped properties.
This fixes a bug where @autoclosure was not propagated from the wrapper's
init(wrappedValue:) to a wrapped argument.
I missed this case when previously improving the
logic here. As it turns out, using the raw anchor
as the root expression from which to derive parent
information is insufficient. This is because it
may not capture relevant parent exprs not a part
of the fix locator.
Instead, pass down a function that can be used to
derive the parent expressions from the constraint
system's own parent map. Also make sure to assign
to `expr` for the UnresolvedMemberChainResultExpr
case to make sure we correctly check for it as a
sub-expression.
Finally, now that we're looking at more parent
exprs, add logic to handle `try` and `await`
parents, as well as ClosureExprs and
CollectionExprs. I couldn't come up with a test
case for CollectionExpr, as we emit different
diagnostics in that case, but it's probably better
to tend on the side of being more future proof
there.
rdar://81512079
* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
In 2eeff365b1 I forgot to copy key path component types when applying a solution to the constraint system. That caused a crash in key path code completion.
Fixes rdar://81118700 [SR-14979]
The added test case fails because the result builder inside `List2` is being type checked twice: Once for every overload of `List2`. Because of the way that result builders are being type checked right now, each overload of `List2` creates a new type variable for the key components in `foo` and the constraint system only keeps track of the key path component -> type mapping for the last solution discovered.
When we are now trying to look up the type of the first key path component for the first solution, the constraint system returns the type variable that is being used by the second solution and simplifying that type variable through the first solution fails because it doesn’t know about the type variable.
To fix the issue, make sure that the solutions keep track of the their type variables associated to key path components. That way the first solution owns its own key path component -> type variable mapping and is thus also able to simplify the type variable it has associated with the component.
Fixes rdar://80522345 [SR-14916]
To check whether the code completion node was type checked in a multi statement closure, we were assuming that we had a code completion *expression* and not considering that we could also complete in a key path component. When applicable, check if the completion key path component has a type to determine if the completion node was type checked as part of a multi-statement closure.
Resolves rdar://80271598 [SR-14891]
AutoClosureExprs created by the constraint system used to be constructed
with the decl context of the constraint system itself. This meant that
autoclosures in expressions nested in closures would initially be
parented onto any enclosing functions rather than the deepest closure
context. When we ran capture analysis and lookup from inside of the body
of these nascent values, we would fail to find declarations brought into
scope by those parent closures. This is especially relevant when
pre-typechecked code is involved since captures for those declarations
will be forced before their bodies have been recontextualized. See
issue #34230 for why we need to force things so early.
The attached test case demonstrates both bugs: The former a bogus lookup
through the parent context that would incorrectly reject this otherwise
well-formed code. The latter is a crash in SILGen when the capture
computation would fail to note $0.
Use the decl context of the solution application target, which is always
going to be the deepest user-written closure expression available to us,
and therefore the deepest scope that can introduce capturable variables.
rdar://79248469
Allow type variable binding producer to record types as they
are being produced. Otherwise it could be possible to re-discover
already explored types during `computeNext()` which leads to
duplicate bindings e.g. inferring fallback `Void` for a closure
result type when `Void` was already inferred as a direct/transitive
binding.
Not-filtering solutions causes unacceptable slownesses in some cases.
For now, filter solutions as normal typechecking does to restore the
performance.
rdar://76714968
Having purpose attached to the contextual type element makes it much
easier to diagnose contextual mismatches without involving constraint
system state.
This saves us from needing to re-match args to params in CSApply and is also
useful for a forthcoming change migrating code completion in argument position
to use the solver-based typeCheckForCodeCompletion api.
rdar://76581093
Conformance constraints could be transferred through conversions,
but that would also require checking implicit conversions
such as optional and pointer promotions for conformance is the
type itself doesn't conform, for that let's add a special constraint
`TransitivelyConformsTo`.
Not all of the unary operators have `CGFloat` overloads,
so in order to preserve previous behavior (and overall
best solution) with implicit Double<->CGFloat conversion
we need to allow attempting generic operators for such cases.
```swift
let _: CGFloat = -.pi / 2
```
`-` doesn't have `CGFloat` overload (which might be an oversight),
so in order to preserve type-checking behavior solver can't be
allowed to pick `-(Double) -> Double` based on overload of `/`,
the best possible solution would be with `/` as `(CGFloat, CGFloat) -> CGFloat`
and `-` on a `FloatingPoint` protocol.
