This would make sure that async function types marked as `@execution(caller)`
have correct isolation.
Also defines all of the possible conversions to and from `caller`
isolated function types.
The flag is specifically NonIsolatedAsyncInheritsIsolationFromContext.
I noticed that we were not codegening @execution(caller) when the flag was
disabled, so I fixed it and added this test.
Put AvailabilityRange into its own header with very few dependencies so that it
can be included freely in other headers that need to use it as a complete type.
NFC.
Right now it is basically a version of nonisolated beyond a few simple cases
like constructors/destructors where we are pretty sure we want to not support
this.
This is part of my bringup strategy for changing nonisolated/unspecified to be
caller isolation inheriting.
the async self-isolated actor initializer case.
Fixes rdar://138394497, a bug where we didn't set up isolation correctly for
an async parameter-isolated initializer, but also probably a non-trivial number
of other latent differences between initializers and normal functions.
This requires two major changes.
The first is that we need to teach SILGen that the isolation of an initializer
is essentially dynamic (as far as SILGen is concerned) --- that it needs to emit
code in order to get the isolation reference. To make this work, I needed to
refactor how we store the expected executor of a function so that it's not
always a constant value; instead, we'll need to emit code that DI will lower
properly. Fortunately, I can largely build on top of the work that Doug previously
did to support #isolation in these functions. The SIL we emit here around delegating
initializer calls is not ideal --- the breadcrumb hop ends up jumping to the
generic executor, and then DI actually emits the hop to the actor. This is a little
silly, but it's hard to eliminate without special-casing the self-rebinding, which
honestly we should consider rather than the weirdly global handling of that in
SILGen today. The optimizer should eliminate this hop pretty reliably, at least.
The second is that we need to teach DI to handle the pattern of code we get in
delegating initializers, where the builtin actually has to be passed the self var
rather than a class reference. This is because we don't *have* a class reference
that's consistently correct in these cases. This ended up being a fairly
straightforward generalization.
I also taught the hop_to_executor optimizer to skip over the initialization of
the default-actor header; there are a lot of simple cases where we still do emit
the prologue generic-executor hop, but at least the most trivial case is handled.
To do this better, we'd need to teach this bit of the optimizer that the properties
of self can be stored to in an initializer prior to the object having escaped, and
we don't have that information easily at hand, I think.
Fixes rdar://87485045.
The generality of the `AvailabilityContext` name made it seem like it
encapsulates more than it does. Really it just augments `VersionRange` with
additional set algebra operations that are useful for availability
computations. The `AvailabilityContext` name should be reserved for something
pulls together more than just a single version.
For synchronous isolated closures passed to unsafe APIs
(the ones that have not been fully concurrency checked)
emit an expected executor check in prolog that would make
sure that they are always used in the expected context.
Resolves: rdar://133415157
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Stored `let` properties of a struct, class, or actor permit
'inout' modification within the constructor body after they have been
initialized. Tentatively remove this rule, only allowing such `let`
properties to be initialized (assigned to) and not treated as `inout`.
Fixes rdar://127258363.
The fix for #72484 didn't properly handle the case of a "generic" context
where all the type parameters had concrete assignments. In this situation,
F.mapTypeIntoContext does not work because the function has no generic
environment.
Fixes rdar://126085573
Failing to map the type of an isolation capture into context
caused assertions in type lowering. Fixes the build of the
swift-distributed-actors package.
First, and I really should've checked this, but global actors do not
require `shared` to return `Self`; adjust the logic to propagate the
right formal type to the erasure logic.
Second, handle attempts to erase the isolation of something isolated to
a distributed actor using the magic Actor conformance that Doug added.
This only works when the actor is local, but it shouldn't be difficult to
enforce that we only attempt to erase isolation what that's true --- we
need to prevent partial application of distributed actors, and we need to
disallow explicit isolated captures of distributed actors when we're not
currently isolated to it. Otherwise, it's not possible to get an
@isolated(any) function value with an isolation that isn't the current
function's isolation, which means it always has to be local.
Fixed rdar://123734019
We do this by pushing the conversion down to the emission of the
closure expression, then teaching closure emission to apply the isolation
to the closure. Ideally, we combine the isolation along with the rest of
the conversion peephole, but if necessary, we make sure we emit the
isolation.
The main piece that's still missing here is support for closures;
they actually mostly work, but they infer the wrong isolation for
actor-isolated closures (it's not expressed in the type, so obviously
they're non-isolated), so it's not really functional. We also have
a significant problem where reabstraction thunks collide incorrectly
because we don't mangle (or represent!) formal isolation into
SILFunctionType; that's another follow-up. Otherwise, I think SILGen
is working.
