Introduce `repairByUsingRawValueOfRawRepresentableType` which is used for
assignment, argument-to-parameter conversions and contextual mismatches.
It checks whether `from` side is a raw representable type and tries
to match `to` side to its `rawValue`.
Also extract logic common for `repairByUsingRawValueOfRawRepresentableType`
and `repairByExplicitRawRepresentativeUse` into `isValueOfRawRepresentable`.
Introduce `repairByExplicitRawRepresentativeUse` which is used for
assignment, argument-to-parameter conversions and contextual mismatches.
It checks whether `to` side is a raw representable type and tries
to match `from` side to its `rawValue`.
Impact of cases where pointer types mismatch after implict optional
wrap(s) should be higher than mismatch alone.
Distinguishing that helps to disambiguate following case (and other similar ones)
without using ranking:
```swift
func foo(_: UnsafePointer<Int>) {}
func foo(_: UnsafePointer<Int>?) {}
func test(_ ptr: UnsafePointer<Float>) {
foo(ptr)
}
```
We currently leave a key path constraint unsolved
if one of its components hasn't yet had its
overload resolved. However, for e.g a missing
member component, the overload type variable will
be bound to a hole and an overload will never be
resolved.
Tweak the logic to consider the key path constraint
trivially solved if one of its components has been
marked as a hole, which will allow the key path
type itself to be marked as a hole.
Resolves SR-12437 & SR-12823.
Resolves rdar://62201037.
Detect situation when it's impossible to determine types for
closure parameters used in the body from the context. E.g.
when a call closure is associated with refers to a missing
member.
```swift
struct S {
}
S.foo { a, b in } // `S` doesn't have static member `foo`
let _ = { v in } // not enough context to infer type of `v`
_ = .foo { v in } // base type for `.foo` couldn't be determined
```
Resolves: [SR-12815](https://bugs.swift.org/browse/SR-12815)
Resolves: rdar://problem/63230293
When simplifying a keypath constraint with a function type binding, single-parameter functions have the parameter type and the return type matched against the keypath root and value; whereas multiple-parameter functions cause an ambiguous failure (in `simplifyKeyPathConstraint`).
Resolves rdar://problem/57930643
If argument is immutable, with or without explicit `&`, let's
diagnose that as mutability problem because suggesting
to add `&` to immutable declaration is not the best possible fix.
Resolves: rdar://problem/62428353
The current approach for type-checking single trailing closures
is to scan backwards from the end of the parameter list, looking
for something that can be passed a closure. This generalizes that
to perform label-matching in reverse on any later trailing closures,
then pick up from that point when trying to place the unlabeled
trailing closure.
The current approach is really not a good language rule, but changing
it as much as we'd really like will require evolution approval and a
source break, so we have to be cautious.
that allows arbitrary `label: {}` suffixes after an initial
unlabeled closure.
Type-checking is not yet correct, as well as code-completion
and other kinds of tooling.
If this is an attempt to fetch members through key path dynamic member lookup
let's not try to apply any property wrapper related fixes because modifying
base type would not change the result.
Resolves: [SR-12520](https://bugs.swift.org/browse/SR-12520)
Resolves: rdar://problem/61911108
All callers can trivially be refactored to use ModuleDecl::lookupConformance()
instead. Since this was the last flag in ConformanceCheckOptions, we can remove
that, too.
Rename `addNewFailingConstraint` to
`recordFailedConstraint`, and call into it
whenever a constraint fails, instead of setting
`failedConstraint`. This ensures that
`-debug-constraints` will always log the constraint
that failed a given scope.
In addition, introduce `retireFailedConstraint`
to cover the common case of retiring a constraint
that just failed.
Retired constraints get added back to the inactive
list when a scope rolls back, and generated
constraints then get removed. So adding a
constraint as both is unnecessary.
Also assert that `addNewFailingConstraint` doesn't
get called with an active constraint.
Make sure we don't end up in a situation where we
have unsolved constraints left over and consider
the system fully solved.
This requires tweaking the type matching code for
dependent members such that a concrete base is
considered a failure rather than being left
unsolved. This should only happen when not in
diagnostic mode, as otherwise we use a hole.
Previously we could allow some invalid coercions to
sneak past Sema. In most cases these would either
cause crashes later down the pipeline or
miscompiles. However, for coercions between
collections, we emitted somewhat reasonable code
that performed a force cast.
This commit aims to preserve compatibility with
those collection coercions that previously
compiled, and emits a warning telling the user to
use either 'as?' or 'as!' instead.
Start visiting transitive fixed bindings for type
variables, and stop visiting adjacencies for
`gatherConstraint`'s `AllMentions` mode.
This improves performance and fixes a correctness
issue with the old implementation where we could
fail to re-activate a coercion constraint, and
then let invalid code get past Sema, causing
either miscompiles or crashes later down the
pipeline.
Unfortunately this change requires us to
temporarily drop the non-ephemeral fix for a couple
of fairly obscure cases where the overload hasn't
yet been resolved. The logic was previously relying
on stale adjacency state in order to re-activate
the fix when the overload is bound, but it's not
connected on the constraint graph. We need to find
a way to connect constraints to unresolved
overloads they depend on.
Resolves SR-12369.
Previously we could prematurely attempt to perform
a bind of class metatypes without checking for
subtyping. Tweak the logic to not perform a bind
if we can't prove that we're dealing with non-class
types.
