Repository navigation
Support panic=abort without #[should_panic] from libtest #62318
Description
When a project wants to turn on panic=abort today, they are forced to choose between
- Re-compiling their whole project with
panic=unwindfor the purpose of running tests (this not only creates longer build times, but also changes the behavior of code between testing and production) - Using a custom test harness (either ad-hoc which requries changes the source code for tests, or by using custom_test_harness which is unstable)
Neither of these solutions are great. One solution that might be palatable is to support compiling panic=abort from libtest, but not support #[should_panic] tests in this mode. This could be advertised with an explicit error message anytime a test with #[should_panic] is run. Later, these could be supported as "death tests" as discussed in #32512.
In Fuchsia we'd really like to switch to panic=abort, and this is the main thing preventing us from doing so.
Reacted by Taylor Cramer, Artem and Chaoses-Ib
Activity
cramertj commentedon Jul 4, 2019
@Centril IMO this is something of a libs question since it interacts with the behavior of libtest and custom test harnesses.
Centril commentedon Jul 5, 2019
@cramertj libtest seems primarily under under T-dev-tools right now and
#[should_panic]is an attribute known by the language (hence T-lang), and it is documented as such in the reference. Custom test frameworks are also not a libs team issue as far as I know.gnzlbg commentedon Aug 17, 2019
We already have custom test frameworks that run each test in a single process (e.g. this one but it is easy to write your own), and those solve more problems than the alternative approaches discussed here (e.g. they trivially support
#![should_panic]test forpanic=abortwhich are essentially death tests).The only downside I see mentioned for this approach is that
custom_test_frameworks are unstable. It might be better to work towards stabilizing these instead of making libtest more complicated to partially-supportpanic=abort, but not quite.Custom test frameworks is one of those things that has been started, is almost there, but not quite yet, and finishing those things is part of this years roadmap.
tmandry commentedon Aug 26, 2019
Agreed that partial support isn't really the way to go. I'm working on fully supporting
panic=abortfrom libtest (see #32512 (comment)).I also think stabilizing custom test frameworks would be nice, but I think panic=abort should be fully supported without one.
tmandry commentedon Aug 14, 2020
This was originally added in #64158 and Cargo support landed in rust-lang/cargo#7460.
#67650 tracks the unstable feature.