- Increase impact of a generic pointer-to-pointer mismatch fix to
match that of a contextual type failure. This allows more specific
fixes to take precedence.
- De-prioritize generic argument mismatch fix when both types are
pointers. This allows pointer-to-pointer conversion produce a
more specific fix.
- De-prioritize fixes that involve `Builtin.RawPointer` or `OpaquePointer`
in parameter positions. This helps to produce better diagnostics
for argument mismatches during pointer initialization e.g.
`UnsafeRawPointer(<pointer>)`.
Instead of infer all of the flags only for anonymous parameters,
let's infer inout/variadic for all type-less parameters - anonymous
and named. This allows to correctly form internal parameter type and
reduce amount of inference in the body (e.g. `BindParam` could be
simplified inline).
We used to represent the interface type of variadic parameters directly
with ArraySliceType. This was awfully convenient for the constraint
solver since it could just canonicalize and open [T] to Array<$T>
wherever it saw a variadic parameter. However, this both destroys the
sugaring of T... and locks the representation to Array<T>. In the
interest of generalizing this in the future, introduce
VariadicSequenceType. For now, it canonicalizes to Array<T> just like
the old representation. But, as you can guess, this is a new staging
point for teaching the solver how to munge variadic generic type bindings.
rdar://81628287
* [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
It's been quite a long time since this unused parameter was introduced.
The intent is to produce the module as a root for the search - that is,
computing the set of conformances visible from that module, not the set
of conformances inside of that module. Callers have since been providing
all manner of module-scoped contexts to it.
Let's just get rid of it. When we want to teach protocol conformance
lookup to do this, we can revert this commit as a starting point and try
again.
* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
Many clients of the conformance lookup operations would prefer to get
an invalid conformance (== there is no conformance) rather than a
missing conformance. Parameterize the conformance lookup operations so
that most callers won't see missing conformances, by filtering them
out at the end. Opt-in those callers that do want to see missing
conformances so they can be diagnosed.
Unfulfilled params get arguments synthesized for them which are added
to the end of the argument list. Later logic to detect out-of-order
arguments and produce relabelling fixes didn't account for them though.
This improves several diagnostics for mislabelled call arguments in the
existing tests.
implicit conversions if the type does not conform and the current score
is equal to the best score.
Implicit conversions will always increase the score, so if the current
score is equal to the best score and an implicit conversion is needed to
satisfy a conformance requirement, the solver would end up pruning that
path later on anyway. It's better to fail early.
Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
If one of the sides in a application result conversion is a hole
it could only mean that the fix has been recorded earlier (at the
point where hole was introduced) and failure at function result
position could be safely ignored.
Resolves: rdar://79757320
If lookup failed to find a member for a pattern match, let's bind
type variable representing such member to a hole right away, otherwise
there is a risk of missing other potential hole locations in pattern
function type (arguments + result type) because pattern matching
doesn't use 'applicable function' constraint.
Resolves: rdar://65667992
Treat actors as being semantically `final` throughout the type checker.
This allows, for example, a non-`required` initializer to satisfy a
protocol requirement.
We're leaving the ABI open for actor inheritance should we need it.
Addresses rdar://78269551.
This commit essentially consistes of the following steps:
- Add a new code completion key path component that represents the code completion token inside a key path. Previously, the key path would have an invalid component at the end if it contained a code completion token.
- When type checking the key path, model the code completion token’s result type by a new type variable that is unrelated to the previous components (because the code completion token might resolve to anything).
- Since the code completion token is now properly modelled in the constraint system, we can use the solver based code completion implementation and inspect any solution determined by the constraint solver. The base type for code completion is now the result type of the key path component that preceeds the code completion component.
This resolves bugs where code completion was not working correctly if the key path’s type had a generic base or result type. It’s also nice to have moved another completion type over to the solver-based implementation.
Resolves rdar://78779234 [SR-14685] and rdar://78779335 [SR-14703]
Let's look through all optionals associated with contextual
type to make it possible to infer parameter/result type of
the closure faster e.g.:
```swift
func test(_: ((Int) -> Void)?) {
...
}
test { $0 + ... }
```
In this case dropping optionality from contextual type
`((Int) -> Void)?` allows `resolveClosure` to infer type
of `$0` directly (via `getContextualParamAt`) instead of
having to use type variable inference mechanism.
type to the locator.
This will provide context for tuple element mismatch diagnostics, instead
of attempting to compute the full tuple type in diagnostics code with a pile
of special cases (see getStructuralTypeContext in CSFix.cpp).
Use `findSelectedOverloadFor` instead of `findResolvedMemberRef`
to cover cases where member is found via base type unwrap, otherwise
conformance constraint would be re-inserted but never re-attempted
which results in a compiler crash.
Resolves: rdar://79268378
While checking whether compiler needs to produce a checked cast warning,
account for the fact that "from" could be less optional than "to" e.g.
`0 as Any?`, so the difference has to be stored as a signed integer
otherwise it's going to underflow and result in a crash or infinite
recursion in the diagnostics.
Resolves: rdar://79523605
With isolated parameters being part of a function's type, check to
ensure that isolated and non-isolated parameters aren't incorrectly
matched. Specifically, it is okay to add `isolated` to a parameter
when there is a subtyping relationship, but not remove it:
```swift
actor A { }
func f(_: isolated A) { }
func g(_: A) { }
func test() {
let _: (isolated A) -> Void = g // okay to add 'isolated'
let _: (A) -> Void = f // error when removing 'isolated'
}
```
Without context synthesized argument would be inferred as a hole,
so let's not record any additional fixes for it if there is no way
to infer it properly from a parameter (which could also be a hole
if it is a generic parameter type).
Resolves: rdar://78781552
If relational constraint has the same dependent member type on both
sides e.g. `$T1.Element == $T1.Element` allow its simplification,
since inference of `$T1` results in dependent member being resolved
to the same concrete type. Otherwise constraint system would be left
with this constraint in inactive state if `$T1` couldn't be resolved
which results in a crash.
Resolves: rdar://78623338
For `async` function types, an actor constraint can be enforced by the callee by hopping executors,
unlike with `sync` functions, so doesn't need to influence the outward type of the function.
rdar://76248452
This helps in situations where there are multiple overloads which
differ only in async effect of their parameters. Passing sync argument
to a sync parameter is always preferred and when detected early
allows solver to avoid some of the duplicate work re-solving for
the rest of the path e.g.
```swift
func test<T>(_: () -> T) {}
func test<T>(_: () async -> T) {}
test {
// sync work
}.op(...)
```
In this case since closure is synchronous first overload of `test`
is always preferred (when it's a match) and solver can skip re-checking
body of the closure and `op` call when it encounters `async` version.
Resolves: rdar://77942193
In overloaded context it's possible that there is an overload that
expects a closure but it can have other issues e.g. different number
of parameters, so in order to pick a better solution let's always
increase a score for overloads where closure is matched against a
non-function type parameter.
When `nil` is passed as an argument to call with multiple overloads
it's possible that this would result in ambiguity where matched
expected argument type doesn't conform to `ExpressibleByNilLiteral`.
To handle situations like this locator for contextual mismatch
has to be adjusted to point to the call where `nil` is used, so
`diagnoseAmbiguityWithFixes` can identify multiple overloads and
produce a correct ambiguity diagnostic.
Resolves: rdar://75514153
Let's make use of a newly added "disable for performance" flag to
allow solver to consider overload choices where the only issue is
missing one or more labels - this makes it for a much better
diagnostic experience without any performance impact for valid code.
`ContextualFailure` is the main beneficiary of additional information
associated with `ContextualType` element because it no longer has to
query solution for "purpose" of the contextual information.
Resolves: rdar://68795727
