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.
With this deprecation emitted by the compiler some codebases that
support many old Swift versions have been forced into warnings they
cannot avoid due to the compatibility promises they made.
This removes the warning but changes no functionality.
We really should be checking for the presence of the ownership
annotation from the top of the parameter's TypeRepr hierarchy, instead
of the bottom.
This fixes some missed edge cases that are now relevant, like
`some ~Copyable`. parameters
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.
The standard library's enqueue() does not play by the same rules -- we
provide "deprecated" implementations in order to remain source/binary
compatible, and showing warnings about this when users make mistake will
only be misleading.