-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
panic=abort support in libtest #64158
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good!
538bdb4
to
327f751
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 |
src/libtest/lib.rs
Outdated
} | ||
} | ||
|
||
impl TryFrom<i32> for TestResult { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to aovid having these TryFrom
impls and instead just use 0 as success, 101 for panic, and everything else as "unconditional failure"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do need to translate panic into success for #[should_panic]
tests in the secondary process, so we can compare the expected failure message if there is one. But yes, I can simplify it down to two codes and remove the impls. It means shuffling around some of the logic in calc_result
which is why I didn't do it originally.
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 |
9556173
to
8f3d298
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 |
8f3d298
to
51c3128
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 |
Could this be sure to check in some tests to For tests I'm thinking of having a |
I'm actually planning on doing exactly that! It's why I requested #63751 :D Sorry progress has been slow on this, I've been juggling a lot of other things this week. |
☔ The latest upstream changes (presumably #64469) made this pull request unmergeable. Please resolve the merge conflicts. |
Oh no worries! Sorry I don't mean to seem rushing at all, afaik it's definitely ok if this takes its time. |
ba69b0b
to
2594b8c
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 |
2594b8c
to
ddcd0fa
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 |
@bors r=alexcrichton p=1 |
📌 Commit 3f0254e has been approved by |
panic=abort support in libtest Add experimental support for tests compiled with panic=abort. Enabled with `-Z panic_abort_tests`. r? @alexcrichton cc @cramertj
☀️ Test successful - checks-azure |
Recently added in rust-lang/rust#64158 the `-Z panic-abort-tests` flag to the compiler itself will activate a mode in the `test` crate which enables running tests even if they're compiled with `panic=abort`. It effectively runs a test-per-process. This commit brings the same support to Cargo, adding a `-Z panic-abort-tests` flag to Cargo which allows building tests in `panic=abort` mode. While I wanted to be sure to add support for this in Cargo before we stabilize the flag in `rustc`, I don't actually know how we're going to stabilize this here. Today Cargo will automatically switch test targets to `panic=unwind`, and so if we actually were to stabilize this flag then this configuration would break: [profile.dev] panic = 'abort' In that case tests would be compiled with `panic=unwind` (due to how profiles work today) which would clash with crates also being compiled with `panic=abort`. I'm hopeful though that we can perhaps either figure out a solution for this and maybe even integrate it with the ongoing profiles work.
Support rustc's `-Z panic-abort-tests` in Cargo Recently added in rust-lang/rust#64158 the `-Z panic-abort-tests` flag to the compiler itself will activate a mode in the `test` crate which enables running tests even if they're compiled with `panic=abort`. It effectively runs a test-per-process. This commit brings the same support to Cargo, adding a `-Z panic-abort-tests` flag to Cargo which allows building tests in `panic=abort` mode. While I wanted to be sure to add support for this in Cargo before we stabilize the flag in `rustc`, I don't actually know how we're going to stabilize this here. Today Cargo will automatically switch test targets to `panic=unwind`, and so if we actually were to stabilize this flag then this configuration would break: [profile.dev] panic = 'abort' In that case tests would be compiled with `panic=unwind` (due to how profiles work today) which would clash with crates also being compiled with `panic=abort`. I'm hopeful though that we can perhaps either figure out a solution for this and maybe even integrate it with the ongoing profiles work.
Needed because rust removed support for "-Zno-landing-pads": rust-lang/rust@bf45975 This caused our Code Coverage build to fail: https://travis-ci.com/github/newsboat/newsboat/jobs/326201747#L651-L656 Also adding "-Zpanic_abort_tests" to allow `panic=abort` in libtest: rust-lang/rust#64158
Hello! This is probably not the best place to ask this, but I wasn't sure where else would be better. I'm trying to figure out how to use this. My goal is to get a core file when my test (either a unit test or an integration test) panics -- e.g., if it blows an assertion. I thought maybe this would happen if I set |
In case it's helpful for anybody else: I tracked down why this behaves the way it does. The implementation in the subprocess installs a panic hook that explicitly exits the process based on the result of the test: As a result, even though the panic strategy is "abort", we never get to the panic runtime because we've exited already. Sorry for my ignorance -- I'm still not clear on the intended behavior here. |
Yes, we have to do something like that to support I'm not sure about your use case, but if it helps..
|
@tmandry Thanks. That makes sense. I did find I could do this with the coredump crate. But what's the purpose of the |
Without it, you can't have |
Add experimental support for tests compiled with panic=abort. Enabled with
-Z panic_abort_tests
.r? @alexcrichton
cc @cramertj