Re: [PATCH v2 1/3] rust: kunit: add #[should_panic] support

[Miguel Ojeda]

On Mon, Nov 2, 2026 at 9:53 PM Nicolás Antinori
<nico.antinori.7@xxxxxxxxx> wrote:
>
> I first thought of disabling `#[should_panic]` tests by directly
> checking the conditions in the macro code. I ended up creating a new
> config because I thought it would be cleaner codewise, if a new
> constraint arises in the future, we just have to add it to the
> `depends on` clause instead of modifying the macro code.

It depends on what we want: if it is meant to be configurable, then it
should be a visible Kconfig symbol; if not, then it should remain an
implementation detail (which could perhaps be a non-visible Kconfig
symbol).

> Yes! they are pretty similar, for `KUNIT_FAULT_TEST`:

Yeah, in that case, I think a new visible Kconfig symbol may be
justifiable -- please see below.

> The only one that is different in `RUST_KUNIT_TESTS` is:
>
> #[test]
> #[should_panic]
> fn rust_test_assert_false_success_with_should_panic() {
>     assert!(false)
> }

I guess it is reasonable to expect this test to pass, since `assert!`
doesn't return and actually panics in normal Rust.

Having said that, I would expect our `should_panic` tests to be
generally about non-`assert*!` panics.

> On top of the reasons I gave above, I tried to follow the same as
> `CONFIG_RUST_BUG_KUNIT_TEST` or `CONFIG_KUNIT_FAULT_TEST` are doing, but
> in this case in particular, the config is not for enabling a test suite
> but for enabling a feature that can affect multiple suites (in this
> patch series the ones behind `CONFIG_RUST_KUNIT_TESTS` and
> `CONFIG_RUST_BITMAP_KUNIT_TESTS`).

Yeah, it is a "mode" -- that is why originally I thought we would try
to just do the right thing automatically, i.e. enable them when
possible, but then when I saw the description of
`CONFIG_KUNIT_FAULT_TEST`:

    Enables fault handling tests for the KUnit framework. These tests may
    trigger a kernel BUG(), and the associated stack trace, even when they
    pass. If this conflicts with your test infrastrcture (or is confusing
    or annoying), they can be disabled by setting this to N.

and I thought it may be fair to have the Kconfig symbol, i.e. it could
also be annoying to see the traces or similar, and thus it may be that
someone needs to disable this.

Having said that, if nobody has asked, we could keep it simple for now
as well -- that may be fine too.

David: what do you think? Is it something that was discussed back then
for that one in C?

Cheers,
Miguel