Cherry-pick of #83128, #82399, and #82878, merged as ea6ca2b5db, 0c4e56174b, and e34eb3331f respectively.
**Explanation**: Currently `test/CMakeLists.txt` can only set `SWIFT_LIT_ARGS` for all tests uniformly. This means that we can't have tests for Embedded Swift with a different set of `lit.py` arguments.
Also, create new `check-swift-embedded-wasi` target from `test/CMakeLists.txt`, tweak `lit.cfg` to support WASI Clang resource dir, exclude unsupported tests based on `CPU=wasm32` instead of `OS=wasi`.
**Scope**: Limited to Embedded Swift test suite.
**Risk**: Low, due to limited scope.
**Testing**: #82878 was incubated on `main` for 2 weeks, #82399 for 3 weeks with no disruption, #83128 merged this week, but enables all these tests on CI, which are consistently passing.
**Issue**: rdar://156585717
**Reviewer**: @bnbarham
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.
Fix the common error of using underscores instead of dashes.
In the rebranch this is an error (lit got more picky), but it also makes sense to fix the tests in the main branch
* Enable running tests from test/Concurrency/ directory in freestanding/minimal presets
* Mark failing Concurrency tests as XFAIL/SKIP on freestanding/minimal
Change the order of paths provided for `DYLD_LIBRARY_PATH` when running
tests for the back-deployed concurrency library, so they supersede the
ones in `/usr/lib/swift`. This way, we can test the back-deployed
concurrency library even on OS's that have the concurrency library in
them. It's not a complete test, because the standard library and
runtime will still vary, but can reproduce many failures more easily.
When using the back-deployed concurrency library, set the lit feature
`back_deploy_concurrency`. Update some tests that are unsupported with
back-deployment to check this.
Finally, add some logging when the concurrency runtime cannot be
tested at all, to help with debugging CI in the future.
We won't look for async functions that can't be used due to availability
unless the availability checking is disabled. Need to disable the
availability checking due to the minimum deploy target being too low for
concurrency.
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
The back-deployed concurrency libraries and older Swift runtimes are
not compatible, so turn off runtime exclusivity checking when running on
older systems. Fixes rdar://84274148.
Tests for crashes aren't available on WebAssembly/WASI since there's no way to intercept traps or crashes on this platform. Trapping causes the whole Wasm VM to shut down with no way to recover from within the test code.
The exclusivity checking support for concurrency relies on having access
to the thread-local set of active memory accesses. Teach the
back-deployed concurrency library to use the same TLS context as the
runtime, which fortunately hasn't change. This fixes the
concurrency exclusivity-checking test in back-deployed configurations
that's tracked by rdar://83064974.
Rather than blanket-disabling concurrency tests when we aren't using a
just-built concurrency library, enable them whenever we have a
suitable concurrency runtime, either just-built, in the OS, or via the
back-deployment libraries.
The implemented semantics are that:
1. Tasks have separate exclusivity access sets.
2. Any synchronous context that creates tasks will have its exclusive access set
merged into the Tasks while the Task is running.
rdar://80492364