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.
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
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 reason why I am doing this is that consuming could cause no implicit
copy errors. Instead __owned will just potentially cause an error if
someone assigns into sending.
rdar://131066640
Previously we would just not print sending. This causes problems since sending
implies a +1 parameter and by removing it we convert the parameter to a +0
parameter, breaking ABI. In this commit, I make it so that when we suppress
sending from argument parameters, we just replace it with consuming so that we
preserve ABI even for callers who do not support sending.
rdar://131066640
I am using this to better test out suppression statements. I am finding that
FileCheck runs into issues with some of the '#if' lines I am trying to match. I
am able to use this option with my asserts only test to uniquely identify a '#if
...' statement and thus have the pattern matching work. I needed this to get the
test in the next commit to pass testing.
These already worked... I am just adding the code coverage before I fix a
different issue in the next commit. This will make it clearer what I am actually
fixing in the next commit when one reads the tests.
The code here was assuming that if we already emitted a compiler guard for
non-Suppressable features, we could avoid doing it for suppressable
features. The problem with this is that compiler() does more than just check for
compiler versions... it also tells the compiler that parser errors in the if
block should be ignored when if evaluates to false.
rdar://129045783
