| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[libc++] Remove workaround for .fail.cpp tests that don't have clang-verify markup By renaming .fail.cpp tests that don't need clang-verify to .compile.fail.cpp, the new test format will not try to compile these tests with clang-verify, and the old test format will work just the same. However, this allows removing a workaround that requires parsing each test looking for clang-verify markup. After this change, a .fail.cpp test should always have clang-verify markup. When clang-verify is not supported by the compiler, we will just check that these tests fail to compile. When clang-verify is supported, these tests will be compiled with clang-verify whether they have markup or not (so they should have markup, or they will fail). This simplifies the test suite and also ensures that all of our .fail.cpp tests provide clang-verify markup. If it's impossible for a test to have clang-verify markup, it can be moved to a .compile.fail.cpp test, which are unconditionally just checked for compilation failure. | 6 年前 | |
[libc++] Remove workaround for .fail.cpp tests that don't have clang-verify markup By renaming .fail.cpp tests that don't need clang-verify to .compile.fail.cpp, the new test format will not try to compile these tests with clang-verify, and the old test format will work just the same. However, this allows removing a workaround that requires parsing each test looking for clang-verify markup. After this change, a .fail.cpp test should always have clang-verify markup. When clang-verify is not supported by the compiler, we will just check that these tests fail to compile. When clang-verify is supported, these tests will be compiled with clang-verify whether they have markup or not (so they should have markup, or they will fail). This simplifies the test suite and also ensures that all of our .fail.cpp tests provide clang-verify markup. If it's impossible for a test to have clang-verify markup, it can be moved to a .compile.fail.cpp test, which are unconditionally just checked for compilation failure. | 6 年前 | |
[runtimes] Rename various libcpp-has-no-XYZ Lit features to just no-XYZ Since those features are general properties of the environment, it makes sense to use them from libc++abi too, and so the name libcpp-has-no-xxx doesn't make sense. Differential Revision: https://reviews.llvm.org/D126482 | 4 年前 | |
[runtimes] Rename various libcpp-has-no-XYZ Lit features to just no-XYZ Since those features are general properties of the environment, it makes sense to use them from libc++abi too, and so the name libcpp-has-no-xxx doesn't make sense. Differential Revision: https://reviews.llvm.org/D126482 | 4 年前 | |
[libc++] fix condition_variable_any hangs on stop_request (#77127) When I implemented condition_variable_any::wait, I missed the most important paragraph in the spec: > The following wait functions will be notified when there is a stop request on the passed stop_token. > In that case the functions return immediately, returning false if the predicate evaluates to false. From https://eel.is/c++draft/thread.condition#thread.condvarany.intwait-1. Fixes #76807 | 2 年前 | |
[runtimes] Rename various libcpp-has-no-XYZ Lit features to just no-XYZ Since those features are general properties of the environment, it makes sense to use them from libc++abi too, and so the name libcpp-has-no-xxx doesn't make sense. Differential Revision: https://reviews.llvm.org/D126482 | 4 年前 | |
[runtimes] Rename various libcpp-has-no-XYZ Lit features to just no-XYZ Since those features are general properties of the environment, it makes sense to use them from libc++abi too, and so the name libcpp-has-no-xxx doesn't make sense. Differential Revision: https://reviews.llvm.org/D126482 | 4 年前 | |
[runtimes] Rename various libcpp-has-no-XYZ Lit features to just no-XYZ Since those features are general properties of the environment, it makes sense to use them from libc++abi too, and so the name libcpp-has-no-xxx doesn't make sense. Differential Revision: https://reviews.llvm.org/D126482 | 4 年前 | |
[libc++] Refactor tests for std::condition_variable (#91530) These tests have always been flaky, which led us to using ALLOW_RETRIES on them. However, while investigating #89083 (using Github provided macOS builders), these tests surfaced as being basically unworkably flaky in that environment. This patch solves that problem by refactoring the tests to make them succeed deterministically. | 2 年前 | |
[libc++] [test] Fix __has_include usage, expand condvarany and spaceship coverage (#94120) Three unrelated, small improvements: * test_macros.h was incorrectly saying __has_include("<version>") instead of __has_include(<version>). + This caused <ciso646> to always be included (noticed because MSVC's STL emitted a deprecation warning). + I searched all of LLVM and found no other occurrences. * thread.condition.condvarany/wait_for_pred.pass.cpp forgot to test anything. + I followed what wait_for.pass.cpp is testing. * Uncomment spaceship test coverage. | 2 年前 | |
[libc++][test] Fix race condition in condition_variable_any tests (#84788) Some tests in condition_variable_any use two shared_lock to guard, which does not work. The fix is to make the writer to use unique_lock | 2 年前 | |
[libc++] Refactor tests for std::condition_variable (#91530) These tests have always been flaky, which led us to using ALLOW_RETRIES on them. However, while investigating #89083 (using Github provided macOS builders), these tests surfaced as being basically unworkably flaky in that environment. This patch solves that problem by refactoring the tests to make them succeed deterministically. | 2 年前 | |
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately. | 2 年前 | |
[libc++][test] Fix race condition in condition_variable_any tests (#84788) Some tests in condition_variable_any use two shared_lock to guard, which does not work. The fix is to make the writer to use unique_lock | 2 年前 | |
[libc++] Refactor tests for std::condition_variable (#91530) These tests have always been flaky, which led us to using ALLOW_RETRIES on them. However, while investigating #89083 (using Github provided macOS builders), these tests surfaced as being basically unworkably flaky in that environment. This patch solves that problem by refactoring the tests to make them succeed deterministically. | 2 年前 | |
[libc++] Refactor tests for std::condition_variable (#91530) These tests have always been flaky, which led us to using ALLOW_RETRIES on them. However, while investigating #89083 (using Github provided macOS builders), these tests surfaced as being basically unworkably flaky in that environment. This patch solves that problem by refactoring the tests to make them succeed deterministically. | 2 年前 | |
[libc++][test] Fix race condition in condition_variable_any tests (#84788) Some tests in condition_variable_any use two shared_lock to guard, which does not work. The fix is to make the writer to use unique_lock | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 6 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 |