This strategy is used to dispatch accesses to 'distributed' computed
property to distributed thunk accessor instead of a regular getter
when access happen outside actor isolation context.
When developing a module for an OS or SDK, one may use declarations from other modules that were recently introduced in the in-development OS. Those declarations will be annotated as available at the deployment target of the client module and yet the symbols for that declaration are not available in all development builds of that OS. If the module strongly links those symbols, it will crash on older development builds of the OS. The `-enable-experimental-ad-hoc-availability` flag is designed to give developers the option of weakly linking all symbols in other modules that were introduced at the deployment target.
This change introduces the basic change in linking behavior but does not address typechecking. Use of the declarations that are made unavailable in this mode will need to be diagnosed and developers will need a way to detect the unavailability at runtime before use.
Resolves rdar://96011550
Objective-C protocols unlike their Swift counterparts could be
nested in other types, so `computeNominalType` has to fetch a
parent for such protocols (if any) just like importer does.
Resolves: rdar://95084142
Before, we were dropping `LeaveClosureBodiesUnchecked` when checking a pattern binding request which caused missing completions inside variables initialized by closures.
rdar://92603748 [#58610]
The three options are now:
* `explicit`: Enforce Sendable constraints where it has been explicitly adopted and perform actor-isolation checking wherever code has adopted concurrency. (This is the default)
* `targeted`: Enforce Sendable constraints and perform actor-isolation checking wherever code has adopted concurrency, including code that has explicitly adopted Sendable.
* `complete`: Enforce Sendable constraints and actor-isolation checking throughout the entire module.
Replace `-warn-concurrency` with a more granular option
`-swift-concurrency=`, where the developer can select one of three
different "modes":
* `off` disables `Sendable` checking for most cases. (This is the Swift
5.5 and Swift 5.6 behavior.)
* `limited` enables `Sendable` checking within code that has adopted
Swift concurrency. (This is currently the default behavior.)
* `on` enables `Sendable` and other concurrency checking throughout
the module. (This is equivalent to `-warn-concurrency` now).
There is currently no distinction between `off` and `limited`. That
will come soon.
Implements the flag part of rdar://91930849.
In some circumstances request for default type is made before
inherited constructor has been validated and storage has been
allocated for invalid type which then triggered a crash during
declaration checking.
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.
In preparation to support cases like this:
```
func test() -> some P {
if #available(...) {
return X()
}
return Y()
}
```
where both `X` and `Y` conform to `P` but are different types.
To ensure that we do not accept code that would require an existential call argument
to be evaluated prior to the call, don't open existential call
arguments if the generic parameter that would capture the opened
existential type is used in any prior parameter.
Note that code generation currently moves the opening of the
existential call argument outside of the call, which is a compiler bug.
This change ensures that we don't accept code would *require* this
out-of-order evaluation and adds a test so we know when we fix this.
This effectively reverts 6823744779
The blanket removal of isolation in default-value expressions had
unintented consequences for important workflows. It's still
a problem that needs to be addressed, but we need to be more precise
about the problematic situations.
SE-0343 is approved so it's time to pull the feature out from behind the
experimental feature flag. This patch pulls it out and deprecates
passing the flag to the frontend so that we can pull it out entirely
eventually.
For ParamDecl instances, the value of this property is not just a function of the introducer (let/var which is a poorly-defined concept for parameters), it's a function of the specifier (inout/__owned/__shared etc). However, computing the specifier also has the side effect of flipping the introducer bits. This appears to be because while the AST uses `isLet` in a syntactic sense "did the user write 'let'?", SIL uses it in a semantic sense "is this property semantically immutable?". These two queries need to be split from one another and the callers migrated. But that is a much larger task for a later time. For now, provide the value of `ParamDecl::isImmutable` to callers since that's the more conservative of the two behaviors.
The bug here is that it's possible for `getSpecifier` to *not* be called before `isLet` is called (usually in SIL). This manifested as a test output divergence on the non-asserts bots since the ASTVerifier was always calling getSpecifier, and most engineers do not build without asserts on at their desk.
rdar://89237318
