Re: [PATCH v2 1/3] rust: kunit: add #[should_panic] support
From: Miguel Ojeda
Date: Tue Nov 03 2026 - 12:55:40 EST
On Tue, Nov 3, 2026 at 3:46 PM David Gow <david@xxxxxxxxxxxx> wrote:
>
> I'd rather this not pass, personally. I think that an assert!() within a
> test should work normally (i.e., it's possible to assert that the test
> state is normal, and a failing assert will fail the test).
>
> I could be talked out of this if it's really unpleasantly different from
> non-kernel Rust, but in that case I think we'd want to make sure that
> kunit_assert!() within a test behaves like a normal assert even in a
> should_panic test.
Yeah, it all boils down to what we mean by `assert!()`.
When I implemented it back then, I intended to allow people to write
the normal asserts they would write (which could help in case we were
to e.g. import code from elsewhere, like a vendored library), as if
would have "Rust-panicked", but not "kernel-panicked".
Viewed in that light, `BUG()` would not necessarily need to make
`should_panic` succeed or not [*], but an `assert!(false)` would need
to make the test succeed. And then we could have a
`should_kernel_panic` and maybe expose a public `kunit_assert!` etc.
to distinguish them and so on.
Having said that, I am not sure how many tests would actually rely on
such differences... I think the core requirement is that, as you say,
we are able to test for Rust panics in functions we call within the
test (and ideally also other Rust panics within the test body too,
when viewed in the light above). But if something simplifies
implementation significantly, then we can consider other things.
[*] I asked an LLM to test what happens in userspace Rust when one
aborts/traps/etc., and it differs in stable between a normal test and
a doctest (with the default `panic=unwind`): essentially, the former
dies, the latter succeeds -- it doesn't seem to be well-defined yet.
There is an issue for the doctest side of it:
https://github.com/rust-lang/rust/issues/143009
and there is a bunch of discussion on the different linked PRs.
Cheers,
Miguel