Instead, use the `%target-swift-5.1-abi-triple` substitution to compile the tests
for deployment to the minimum OS versions required for use of _Concurrency APIs.
The effect of passing -enable-copy-propagation is both to enable the
CopyPropagation pass to shorten object lifetimes and also to enable
lexical lifetimes to ensure that object lifetimes aren't shortened while
a variable is still in scope and used.
Add a new flag, -enable-lexical-borrow-scopes=true to override
-enable-copy-propagation's effect (setting it to ::ExperimentalLate) on
SILOptions::LexicalLifetimes that sets it to ::Early even in the face of
-enable-copy-propagation. The old flag -disable-lexical-lifetimes is
renamed to -enable-lexical-borrow-scopes=false but continues to set that
option to ::Off even when -enable-copy-propagation is passed.
Rather than blanket-disabling concurrency tests when we aren't using a
just-built concurrency library, enable them whenever we have a
suitable concurrency runtime, either just-built, in the OS, or via the
back-deployment libraries.
When accessing a static property isolated to a
global-actor, such as MainActor, a `hop_to_executor`
was not being emitted. This was caught by an assertion
I had left to catch such cases, but of course in release
builds this will lead to incorrect SIL, etc.
This issue revealed some other problems with how
the implementation was done for other kinds of
accesses starting from a static property, e.g.,
emitting a redundant hop for the same access.
This was fixed by modelling the actor-isolation
placed into a component as only being accessible
by consuming it from the component. This prevents
the emission of the hops more than once.
Thus, the regression test was updated to catch
unexpected hop_to_executor instructions.
Resolves rdar://78292384
Tasks shouldn't normally hog the actor context indefinitely after making a call that's bound to
that actor, since that prevents the actor from potentially taking on other jobs it needs to
be able to address. Set up SILGen so that it saves the current executor (using a new runtime
entry point) and hops back to it after every actor call, not only ones where the caller context
is also actor-bound.
The added executor hopping here also exposed a bug in the runtime implementation while processing
DefaultActor jobs, where if an actor job returned to the processing loop having already yielded
the thread back to a generic executor, we would still attempt to make the actor give up the thread
again, corrupting its state.
rdar://71905765
