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.
The actual issue in this cases is that the type of a sequence
doesn't conform to `Sequence` protocol, which means that it's
impossible to deduce a base for `next` call.
Instead of asking SILGen to build calls to `makeIterator` and
`$generator.next()`, let's synthesize and type-check them
together with the rest of for-in preamble. This greatly simplifies
interaction between Sema and SILGen for for-in statements.
Experimental features can only be enabled in non-production (+Asserts)
builds. They can be detected with `hasFeature` in the same manner as
"future" features.
The `-enable-experimental-feature X` flag will also look for future
features by that name, so that when an experimental feature becomes an
accepted future feature, it will still be enabled in the same manner.
Switch variadic generics over to this approach, eliminating the
specific LangOption for it.
Ambiguities like:
```
struct S {
init(v: Int) {}
init(v: Int, _: () -> Void) {}
func callAsFunction(_: () -> Void) {}
}
S(v: 42) {
}
```
Should always be resolved in favor of choice that doesn't require
injection of `.callAsFunction`, so let's try to avoid solving if
such an overload has already been found.
Fixes an oversight where `inout` -> C pointer conversion wasn't covered
by implementation of new pointer conversion semantics proposed by SE-0324.
Resolves: rdar://92583588
`RelabelArguments` cannot possibly diagnose this issue because there
are no argument lists in this case. Let's report contextual mismatch
instead.
Resolves: https://github.com/apple/swift/issues/59058
If there is a call to `init` on a callable type that has a trailing
closure, let's avoid filtering because it's impossible to tell whether
a trailing closure belongs to an `init` call or implicit `.callAsFunction`
that would be attempted after it.
Resolves: rdar://92912878
It is not the case that `any P` satisfies a class bound
even if the existential is a composition with an exact
match to the class bound. The resulting existential box
must be opened as the exact class type before this conversion
can succeed.
This appears to be a regression from Swift 5.1, which was the last
Swift compiler that banned this typing rule.
rdar://92358570
