-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Support rustc's -Z panic-abort-tests
in Cargo
#7460
Conversation
r? @Eh2406 (rust_highfive has picked a reviewer for you, use r? to override) |
r? @ehuss |
@@ -639,7 +639,7 @@ fn generate_targets<'a>( | |||
) -> CargoResult<Vec<Unit<'a>>> { | |||
// Helper for creating a `Unit` struct. | |||
let new_unit = |pkg: &'a Package, target: &'a Target, target_mode: CompileMode| { | |||
let unit_for = if bcx.build_config.mode.is_any_test() { | |||
let unit_for = if target_mode.is_any_test() { |
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.
@ehuss I'll want to draw your eye particularly to this line. I sort of blindly made this change assuming that this is the best interpretation nowadays, and it is required to remove the check for mode.is_any_test()
in profiles.rs
above
Would it be possible to squelch this warning when So I see a few different options to handle
I'm curious, disregarding the above issue, can you think of any reason not to stabilize this feature as-is? Are there concerns about performance running a process per test? Or are there any situations where someone has an From my perspective, this seems like it is much nicer for |
4b5087f
to
46bf31f
Compare
Sorry for the delay, back now though! I hadn't though too too much about stabilizing this option honestly, I just wanted to make sure we at least tried to prove it out in Cargo before we stabilize it in rustc to make sure it works. I suspect the stabilization here will be pretty tricky and it probably won't end up looking like this PR in the long run. I'm not certain that Cargo would correctly handle different configurations of tests today. For example if you configure I think the best way we'll want to implement this is long-term we just ignore the The biggest thing I'm worried about is if we've accidentally conditioned users the wrong way, but I had forgotten about this warning. Given that we've always warned we can probably reasonly assume no one has Ok that's a bit rambly, but how about:
And... I think that'd do it? |
I like the strategy of ignoring panic for Just an element of curiosity, I looked at how crates.io crates were using the
It seems like a pretty small number to me overall. Perhaps most abort crates are not published? (Which would not surprise me.) |
46bf31f
to
c6471ff
Compare
Heh, seems reasonable to me! Should be done now. I think now the stabilization strategy for this would look like "remove everything related to it being unstable" and that should be it! |
Sounds good to me. Looks like 2 tests need to be updated for the new behavior. |
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.
We've always ignored the `panic` settings configured in test/bench profiles, so this just continues to ignore them but in a slightly different way.
c6471ff
to
9cfdf4d
Compare
@bors: r=ehuss |
📌 Commit 9cfdf4d has been approved by |
⌛ Testing commit 9cfdf4d with merge 7a13e3858bde1da98ac44ee8208980c0dce45710... |
💔 Test failed - checks-azure |
@bors: r=ehuss |
📌 Commit 269624f has been approved by |
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.
☀️ Test successful - checks-azure |
Update cargo 6 commits in 3a9abe3f065554a7fbc59f440df2baba4a6e47ee..3ba5f27170db10af7a92f2b682e049397197b8fa 2019-10-15 15:55:35 +0000 to 2019-10-22 15:05:18 +0000 - Fix typo in `cargo install --profile` help (rust-lang/cargo#7532) - Use stricter -Z flag parsing. (rust-lang/cargo#7531) - Set timestamp on generated files in archive to now (rust-lang/cargo#7523) - Support rustc's `-Z panic-abort-tests` in Cargo (rust-lang/cargo#7460) - rustfmt for nightly changes. (rust-lang/cargo#7526) - Allow --all-features in root of virtual workspace. (rust-lang/cargo#7525)
Update cargo 6 commits in 3a9abe3f065554a7fbc59f440df2baba4a6e47ee..3ba5f27170db10af7a92f2b682e049397197b8fa 2019-10-15 15:55:35 +0000 to 2019-10-22 15:05:18 +0000 - Fix typo in `cargo install --profile` help (rust-lang/cargo#7532) - Use stricter -Z flag parsing. (rust-lang/cargo#7531) - Set timestamp on generated files in archive to now (rust-lang/cargo#7523) - Support rustc's `-Z panic-abort-tests` in Cargo (rust-lang/cargo#7460) - rustfmt for nightly changes. (rust-lang/cargo#7526) - Allow --all-features in root of virtual workspace. (rust-lang/cargo#7525)
Remove unused profile support for -Zpanic-abort-tests This removes the vestigial `PanicSetting::Inherit` setting. This was initially introduced in #7460 which added `-Zpanic-abort-tests`. This was needed at the time because `test` and `dev` profiles were separate, but they were inter-mixed when running `cargo test`. That would cause a problem if the unwind/abort settings were mixed. However, with named profiles, `test` now inherits from `dev`, so this is no longer necessary. Now that named profiles are stable, support for the old form is no longer necessary.
Recently added in rust-lang/rust#64158 the
-Z panic-abort-tests
flagto the compiler itself will activate a mode in the
test
crate whichenables running tests even if they're compiled with
panic=abort
. Iteffectively 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 inpanic=abort
mode. While I wanted to be sure to add support for this inCargo before we stabilize the flag in
rustc
, I don't actually know howwe're going to stabilize this here. Today Cargo will automatically
switch test targets to
panic=unwind
, and so if we actually were tostabilize this flag then this configuration would break:
In that case tests would be compiled with
panic=unwind
(due to howprofiles work today) which would clash with crates also being compiled
with
panic=abort
. I'm hopeful though that we can perhaps either figureout a solution for this and maybe even integrate it with the ongoing
profiles work.