Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
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.
Specifically, I am transforming it from "may cause a race" -> "may cause a data
race". Adding data is a small thing, but it adds a bunch of nice clarity.
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
I am doing this since it isn't always going to be an access. We may not have
memory. We are talking about uses here!
I was able to just use sed so it was an easy fix.
As an example of the change:
- // expected-note @-1 {{'x' is transferred from nonisolated caller to main actor-isolated callee. Later uses in caller could race with potential uses in callee}}
+ // expected-note @-1 {{transferring disconnected 'x' to main actor-isolated callee could cause races in between callee main actor-isolated and local nonisolated uses}}
Part of the reason I am doing this is that I am going to be ensuring that we
handle a bunch more cases and I wanted to fix this diagnostic before I added
more incaranations of it to the tests.
This is just a pseudo-why are these two things part of the same region error. I
am going to remove this for now and the proper form of this diagnostic will come
back when I land the region history functionality.
A name diagnostic looks as follows:
Some notes:
1. VariableNameUtils still doesn't pattern match all cases. In the cases where
we fail to pattern match, I fall back to the old diagnostics. I am going to be
adding tests/etc specific to VariableNameUtils in a later patch.
2. I took this as an opportunity to begin preparing to change the diagnostics
into diags of the following form:
a. The main diagnostic is changed to something short "transferring non-Sendable
%0 could yield races with later accesses".
b. I added a longer note at the same location that explains that our caller is
in a specific isolation domain and our callee is isolated differently.
c. I added a note on the definition location of the identified value.
Use an optional isolated parameter to this new `next(_:)` overload to
keep it on the same actor as the caller, and pass `#isolation` when
desugaring the async for..in loop. This keeps async iteration loops on
the same actor, allowing non-Sendable values to be used with many
async sequences.
I tried to make them shorter and standardized on "; later accesses could race"
as the mark on a diagnostic that the problem was that a race was occuring
(before we had several small different variations).
async for-in loops.
Async iterators are not `Sendable`; they're only meant to be used from
the isolation domain that creates them. But the `next()` method runs on
the generic executor, so calling it from an actor-isolated context passes
non-`Sendable` state across the isolation boundary. `next()` should
inherit the isolation of the caller, but for now, use the opt out.
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.
Upcoming and experimental features are supported via command-line flags
and also in the SwiftPM manifest. Introduce it as an experimental
feature so that it can be enabled via SwiftPM without having to resort
to unsafe flags.
The `StrictConcurrency` experimental feature can also provide a
strictness level in the same manner as `-strict-concurrency`, e.g.,
`StrictConcurrency=targeted`. If the level is not provided, it'll be
`complete`.
Note that we do not introduce this as an "upcoming" feature, because
upcoming features should be in their final "Swift 6" form before
becoming available. We are still tuning the checking for concurrency.
