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.
There is no `%swift-frontend-target` subsitution in test, which is
actually `%target-swift-frontend`. The wrong spelling is actually
interpreted by lit as `%swift`-frontend-target, and surprising didn't
break any tests as the last argument from subsitution is
`-define-availability` so it just leads to an very akward availability
definition.
Instead of emitting an warning to the diagnostic engine, return the
plugin loading error as the result of the request. So that the user
can decide to emit it as a warning or an error.
This is a very large diagnostic, where the second half is mostly aimed
at macro authors rather than clients. Cut it down to the base
diagnostic.
Resolves rdar://113646544.
Previously, the compiler fails to read the result from 'getCapability'
IPC message, it used to just emit a fatalError and crashed.
Instead, propagate the error status and diagnose it.
rdar://108022847
