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.
The locator needs to much what was produced by constraint generator
otherwise Double<->CGFloat implicit coercion wouldn't be able to
find the overload choice.
Constraint generator records conversion between source and destination
types as anchored on an assignment, which means that coercion has to do
the same in case restrictions (like Double<->CGFloat conversion) depend
on locators to retrieve information for the solution.
Just like in case of array elements, the locator needs to much what
was produced by constraint generator otherwise Double<->CGFloat implicit
coercion wouldn't be able to find the overload choice.
The type checker is now permitting `@Sendable` closures whose captures
can be by-reference, because we do not error. Remove an aspirational
SIL verifier check that banned this.
When referring to a `@preconcurrency` function as a value, use the normal
type for the initial declaration reference and then introduce an
appropriate function conversion expression to the adjusted type.
Fixes more issues related to rdar://94597323.
When we have adjusted the type of a dynamic member reference (e.g.,
for `@objc optional` methods) due to `@preconcurrency` or similar,
form the original dynamic member reference based on the original type
and then introduce an appropriate conversion. This better reflects the
adjustment in the AST, eliminating a SIL verifier crash.
Fixes rdar://94597323.
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
Using `replaceCovariantResultType`, which looks through optionals, to
substitute the container type for the result type would add an extra
level of optionality to the result type whenever the container type was
`Optional`, causing a crash later in the game. Besides, we don't have to
do this in the first place, because we know these types match in the case
of an initializer (neglecting optionality).
If distributed memeber is referenced on a base that represents
a result of some expression which is not a variable, parameter,
or a capture it should always be dispatched via a thunk.
Replace distributed member references with distributed thunks
when access happens outside of distributed actor context. This
significantly simplifies distributed compute properties implementation.
Property wrappers trigger initializer synthesis. Synthesized
initializers should not be re-typechecked when encountered e.g.
while re-solving closure with a different contextual type.
Resolves: https://github.com/apple/swift/issues/59294
Resolves: rdar://94506352
* Delegated-to `Optional` ctors were always handled as if they were failable, resulting in false-positive delegation errors.
* Delegations via `try?` were not diagnosed if the called ctor had IUO failability on top of being `throws`. SILGen would then handle the `try?` as if it was a `try!`.
* Delegations via `try?` were diagnosed with the wrong message if the `try?` was nested inside a `try!`, e.g. `try! try self.init(nonFailable:)`
* If there are issues with both `try?` and failability of the called initializer, diagnose both.
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.
Previously for-in target was actually an expression target, which means
certain type-checking behavior. These changes make it a standalone target
with custom behavior which would allow solver to introduce implicit
`makeIterator` and `next` calls and move some logic from SILGen.
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.
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
When performing conversions to an existential that involves Sendable,
introducing missing conformances as needed to allow the type-check to
succeed and then (later) they'll be diagnosed appropriately.
Fixes rdar://89992095.
When construction call is rewritten into a tuple conversion,
rewriter has to make sure that AST types are reset otherwise
it would end up with types set by `packIntoImplicitTupleOrParen`
which could contain l-values.
Resolves: rdar://90366182
For all of the `build*` calls, let's use a special variable declaration
`$builderSelf` which refers to a type of the builder used. This allows
us to remove hacks related to use of `TypeExpr`. Reference to `$builderSelf`
is replaced with `TypeExpr` during solution application when the builder
type is completely resolved.
