Commit Graph

16 Commits

Author SHA1 Message Date
Max Desiatov
ab7cd238fd [6.2] test/CMakeLists.txt: run Embedded Swift for Wasm tests (#83287)
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
2025-07-26 09:48:47 +01:00
Allan Shortlidge
c02fc4724d Tests: Remove -disable-availability-checking from many Concurrency tests.
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.
2024-10-18 16:21:51 -07:00
Alex Lorenz
0f9a69c712 android test fixes 2024-05-28 12:59:26 -07:00
Erik Eckstein
70981cf95f tests: fix misspelled check prefixes
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
2022-11-08 17:27:48 +01:00
Kuba (Brecka) Mracek
7853184ed6 Enable running tests from test/Concurrency/ directory in freestanding/minimal presets (#61835)
* Enable running tests from test/Concurrency/ directory in freestanding/minimal presets

* Mark failing Concurrency tests as XFAIL/SKIP on freestanding/minimal
2022-11-04 09:07:27 -07:00
Doug Gregor
7589520f7c Make back-deployed concurrency library testable on OS's that have the library.
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.
2022-06-06 14:37:17 -07:00
Josh Soref
58880533bc Spelling concurrency (#42547)
* spelling: access is

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: executor

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: making

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: reabstraction

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: releasing

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: successes

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

* spelling: whoopsie

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>
2022-04-22 15:05:20 -07:00
Evan Wilde
a53c727e90 Disable availability checking on failing tests
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.
2021-12-20 13:06:35 -08:00
Karoy Lorentey
47956908b7 [Concurrency] SwiftStdlib 5.5 ⟹ SwiftStdlib 5.1 (usages)
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.
2021-10-28 14:36:36 -07:00
Doug Gregor
18323ddda9 Disable runtime exclusivity checking when using back-deployed concurrency.
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.
2021-10-14 15:40:33 -07:00
Max Desiatov
8481354f48 test: disable Concurrency/Runtime/exclusivity.swift on WASI
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.
2021-10-05 10:27:29 +01:00
Doug Gregor
2747285417 Always use the same TLS context as the runtime for back-deployed concurrency
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.
2021-10-01 17:13:02 -07:00
Doug Gregor
3ee09a2298 Switch concurrency runtime tests to "REQUIRES: concurrency_runtime"
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.
2021-09-13 12:34:20 -07:00
Doug Gregor
eeeea49764 Remove -enable-experimental-concurrency almost everywhere. 2021-07-26 21:24:43 -07:00
Michael Gottesman
2edc32b8e4 [concurrency] Test exclusivity just use crashing tests rather than FileCheck tests since the FileCheck tests are too unstable given concurrency.
I also migrated some of the tests (out of an abundance of caution) into the
executable test cases.
2021-07-23 11:49:15 -07:00
Michael Gottesman
0aec81614d [exclusivity] Add support for Task local exclusivity access sets.
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
2021-07-22 13:25:10 -07:00