These will never appear in the source language, but can arise
after substitution when the original type is a tuple type with
a pack expansion type.
Two examples:
- original type: (Int, T...), substitution T := {}
- original type: (T...), substitution T := {Int}
We need to model these correctly to maintain invariants.
Callers that previously used to rely on TupleType::get()
returning a ParenType now explicitly check for the one-element
case instead.
If the failure is not reflected in constraint system it would let
the solver to form a _valid_ solution as if the constraint between
the type variable and the unresolved dependent member type never
existed.
Resolves: https://github.com/apple/swift/issues/60649
The outermost wrapper is the one at index `0` in the wrapper list
but it's easy for humans to make a reverse assumption since outermost
is the back of the list. Let's add a dedicated method to reduce error
probability of the property wrapper APIs.
Previously we relied on `TupleTypeElt::getType`
returning an `InOutType` to fail the tuple type
matching logic. Instead, add logic to reject any
inout arguments up-front with a more specific
diagnostic.
Also, while we're here, strip the `_const`
parameter flag, as it's not something that needs
to be considered for tuple construction.
Move off `Type` based requests and onto `Decl`
based requests, utilizing name lookup's
`extractDirectlyReferencedNominalTypes` utility.
This allows us to better cache the results, and
avoids the need to guard against type variable
inputs when deciding whether or not to cache.
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
Previously only static methods found on protocols were allowed but
it is reasonable to reference a typealias to perform an implicit call
to `.init` on its underlying type.
Resolves: rdar://88513939
When `&` is misplaced it creates r-value -> l-value mismatch
in the code which is just a consequence and shouldn't be diagnosed.
Resolves: rdar://96631324
Rather than only setting the isolated-by-preconcurrency bit during
constraint application, track the closures it will be set for as part
of the constraint system and solution. Then, use that bit when
performing "strict concurrency context" checks and type adjustments,
so we don't treat an inferred-to-by-`@Sendable`-by-preconcurrency
closure in the solver as if it weren't related to preconcurrency.
Fixes the spurious warning from
https://github.com/apple/swift/issues/59910.
This avoids us having to go down the less-efficient "salvage" path when
dealing with concurrency issues. It also fixes overloading behavior
when dealing with `@preconcurrency` and `@Sendable` functions,
such as in https://github.com/apple/swift/issues/59909.
Rather than re-using `DiagnosticBehavior` to describe how a fix should
act, introduce `FixBehavior` to cover the differences between (e.g.)
always-as-awarning and downgrade-to-warning. While here, split the
`isWarning` predicate into two different predicates:
* `canApplySolution`: Whether we can still apply a solution when it
contains this particular fix.
* `affectsSolutionScore`: Whether
These two predicates are currently tied together, because that's the
existing behavior, but we don't necessarily want them to stay that way.
Instead of the `warning` Boolean threaded through the solver's
diagnostics, thread `DiagnosticBehavior` to be used as the behavior
limit. Use this for concurrency checking (specifically dropped
`@Sendable` and dropped global actors) so the solver gets more control
over these diagnostics.
This change restores the diagnostics to a usable state after the prior
change, which introduced extra noise. The only change from existing
beavior is that dropping a global actor from a function type is now
always a warning in Swift < 6. This is partly intentional, because
there are some places where dropping the global actor is well-formed.
Unfortunately current approach of making a conversion independent of location
doesn't work when conversion is required for multiple arguments to the
same call because solver expects that either there are no Double<->CGFloat
conversions, or one of them has already been applied which is not the case.
The reason why locations weren't preserved in the first place is due to
how a solution is applied to AST - AST is mutated first and then, if there
are any conversions, they are applied to the already mutated version of
original AST. This creates a problem for Double<->CGFloat which depends
on an overload choice of injected call and it's impossible to find it based
on the mutated AST. But it turns out that this is only an issue in two
specific cases - conversions against contextual type and after optional injection.
This situations could be mitigated by dropping parts of the locator which are
unimportant for the Double<->CGFloat conversion - anchor in case of contextual
and `OptionalPayload` element(s) in case of optional injection.
Resolves: https://github.com/apple/swift/issues/59374
Before these changes filtering would not favor some members because their
function types have `escaping` bit set when argument function type never
has it.
Double/CGFloat implicit conversion is one of such cases where `CGFloat.init`
overloads have `escaping` bit, which leads to solver checking more overloads
then it should.
Note that the difference in effects such as `async` is going to be handled
by scoring and ranking after partial solution is produced, so overloads that
differ only in `async` or `throws` are still going to be solved for as part
of "favored" set.
Detect that extraneous closure belongs to `.init` call on a callable
type and let the solver inject `.callAsFunction` before fixing it.
This prevents incorrect "extraneous trailing closure" diagnostic when
issue is located inside of the closure itself.
If current parameter cannot accept a trailing closure, let's match
current closure argument to it only if there is absolutely no
possible other choice e.g. no other parameters (defaulted or not)
that could accept the closure via a less restrictive backward scan.
