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.
TLDR: This makes it so that we always can parse sending/transferring but changes
the semantic language effects to be keyed on RegionBasedIsolation instead.
----
The key thing that makes this all work is that I changed all of the "special"
semantic changes originally triggered on *ArgsAndResults to now be triggered
based on RegionBasedIsolation being enabled. This makes a lot of sense since we
want these semantic changes specifically to be combined with the checkers that
RegionBasedIsolation turns on. As a result, even though this causes these two
features to always be enabled, we just parse it but we do not use it for
anything semantically.
rdar://128961672
This fixes a few issues I missed in the past bit of commits.
I need to fix one issue around async let, but I am going to fix it when I do a
sweep across async let.
I added a disable flag -disable-region-based-isolation-with-strict-concurrency
so that we do not need to update the current tests. It is only available when
asserts are enabled to ensure users cannot use it.
rdar://125918028
This means that:
1. In test cases where minimal is the default (swift 5 without
-warn-concurrency), I added RUN lines for targeted, complete, and complete +
sns.
2. In test cases where complete is the default (swift 6, -warn-concurrency,
specified complete with -strict-concurrency), I added a send non-sendable run
line.
In each of these cases, I added additional expected-* lines as appropriate so
the tests can compile in each mode successfully.
This patch updates the `actor class` spelling to `actor` in almost all
of the tests. There are places where I verify that we sanely handle
`actor` as an attribute though. These include:
- test/decl/class/actor/basic.swift
- test/decl/protocol/special/Actor.swift
- test/SourceKit/CursorInfo/cursor_info_concurrency.swift
- test/attr/attr_objc_async.swift
- test/ModuleInterface/actor_protocol.swift
Replace the existing warning about any access to a local variable from
concurrently-executing code with a more tailored error:
concurrently-executing code may read a mutable varable, but cannot
modify it. This is safe so long as we either always do by-value
captures in concurrent closures or we ensure that no mutation of that
variable can occur after the point of capture.
We'll follow up with one of those. For now... be careful out there.
Since we're promoting this to an error, narrow it down to concurrent
closures and local functions, dropping the assumption that escaping
closures "may execute concurrently."
Make sure that we check the isolation of the context in which a reference
to `self` is made, rather than the context in which `self` is declared,
when checking whether we are within actor-isolated code. This ensures
that we report errors as actor-isolation errors rather than falling
back to the "may execute concurrently with" checking.
The initializer of an 'async let' is executed as a separate child task
that will run concurrently with the main body of the function. Model
the semantics of this operation by wrapping the initializer in an
async, escaping autoclosure (representing the evaluation of the child
task), and then a call to that autoclosure (to
This is useful both for actor isolation checking, which needs to treat
the initializer as executing in concurrent code, and also (eventually)
for code generation, which needs to have that code in a closure so
that it can be passed off to the task-creation functions.
There are a number of issues with this implementation producing
extraneous diagnostics due to this closure transformation, which will
be addressed in a follow-up commit.
