-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add --force-run-in-process unstable option to libtest #66415
Conversation
a589816
to
a662d0e
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
a662d0e
to
808ad17
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Looks like this is an unstable flag and seems reasonable to me! r=me with CI failure fixed |
808ad17
to
84070d8
Compare
@bors r=alexcrichton rollup |
📌 Commit 84070d8 has been approved by |
…excrichton Add --force-run-in-process unstable option to libtest When running tests with `-Zpanic_abort_tests`, it's sometimes desirable to fall back to the old behavior of only running tests in-process. This comes in handy if the system process launcher is unavailable, or the test code somehow expects all tests to be run in the same process. For example, in Fuchsia we have unit tests that actually test the process launcher itself, in which case we can't use the process launcher to run the tests :). r? @alexcrichton cc @cramertj,@petrhosek
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@bors r- ^ |
84070d8
to
d252ba3
Compare
@bors r=alexcrichton |
📌 Commit d252ba3 has been approved by |
…excrichton Add --force-run-in-process unstable option to libtest When running tests with `-Zpanic_abort_tests`, it's sometimes desirable to fall back to the old behavior of only running tests in-process. This comes in handy if the system process launcher is unavailable, or the test code somehow expects all tests to be run in the same process. For example, in Fuchsia we have unit tests that actually test the process launcher itself, in which case we can't use the process launcher to run the tests :). r? @alexcrichton cc @cramertj,@petrhosek
…excrichton Add --force-run-in-process unstable option to libtest When running tests with `-Zpanic_abort_tests`, it's sometimes desirable to fall back to the old behavior of only running tests in-process. This comes in handy if the system process launcher is unavailable, or the test code somehow expects all tests to be run in the same process. For example, in Fuchsia we have unit tests that actually test the process launcher itself, in which case we can't use the process launcher to run the tests :). r? @alexcrichton cc @cramertj,@petrhosek
Rollup of 5 pull requests Successful merges: - #66350 (protect creation of destructors by a mutex) - #66407 (Add more tests for fixed ICEs) - #66415 (Add --force-run-in-process unstable option to libtest) - #66427 (Move the JSON error emitter to librustc_errors) - #66441 (libpanic_unwind for Miri: make sure we have the SEH lang items when needed) Failed merges: r? @ghost
When running tests with
-Zpanic_abort_tests
, it's sometimes desirable to fall back to the old behavior of only running tests in-process. This comes in handy if the system process launcher is unavailable, or the test code somehow expects all tests to be run in the same process.For example, in Fuchsia we have unit tests that actually test the process launcher itself, in which case we can't use the process launcher to run the tests :).
r? @alexcrichton
cc @cramertj,@petrhosek