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.
Rather than write an appoximation of the "is distributed thunk" check
within the type checker, use the new actor reference checking logic with
a referenced actor that is synthesized from the information in the
constraint system.
Start collapsing the several implementations of actor isolation checking
into a single place that determines what it means to reference a declaration
from a given context, potentially supplying an instance for an actor. This
is partly cleanup, and partly staging for the implementation of the
Sendable restrictions introduced in SE-0338. The result of this check
falls into one of three categories:
* Reference occurs within the same concurrency domain (actor/task)
* Reference leaves an actor context to a nonisolated context (SE-0338)
* Reference enters the context of the actor, which might require a
combination of implicit async, implicit throws, and a "distributed" check.
Throughout this change I've sought to maintain the existing semantics,
even where I believe they are incorrect. The changes to the test cases
are not semantic changes, but reflect the unification of some
diagnostic paths that changed the diagnostic text but not when or how
those diagnostics are produced. Additionally, SE-0338 has not yet been
implemented, although this refactoring makes it easier to implement
SE-0338.
Use this new actor isolation checking scheme to implement the most
common actor-isolation check, which occurs when accessing a member of
an instance.
While synthesizing `~=` application for multi-statement closures or
result builder, solver shouldn't set types directly to newly
created AST nodes because they might not be fully resolved, instead
such types have to be recorded in the constraint system and then
set during solution application.
Resolves: rdar://91145060.
