Re: [PATCH RFC 0/3] rust: kunit: #[should_panic] and same test name with different #[cfg(...)] support

[Gary Guo]

On Tue Sep 22, 2026 at 8:56 AM BST, David Gow wrote:
> Le 16/09/2026 à 03:33, Nicolás Antinori a écrit :
>> - Is it ok to 'stringify' the configuration so it can be distinguished
>>    in the report? Would you prefer something like `_case_1` `_case_2` ..
>>    instead?

I also don't like the stringifcation of cfgs.

>
> I don't _like_ this: my preference would be for us to keep the same 
> name, and just not emit a test_case for anything which should be 
> compiled out with cfg. Unfortunately, implementing that is a bit harder 
> than would be ideal: we need a way of evaluating the cfg() arguments in 
> a proc macro, I think. (Ultimately, because otherwise there's no way of 
> statically determining the length of the TEST_CASES array?)

This is possible with a trick. In pin-init we have a similar need, so what I do
is for

    #[macro]
    struct Foo {
        #[cfg(a)]
        bar: u32,
    }

to be expanded to

    #[cfg(a)]
    #[macro]
    struct Foo {
        bar: u32
    }

    #[cfg(not(a))]
    #[macro]
    struct Foo {
    }

However, for kunit I don't think that's needed. Deduplicating the names
should be sufficient?

Best,
Gary

>
> Unless you've got a good idea how to fix this, though, I'm happy to put 
> up with adding the configs to the name for now. Though if there's a nice 
> way to make the names shorter 
> (rust_test_kunit_parse_cfg_in_kunit_test_cfg_config_rust_kunit_selftest_equals_n 
> is definitely too long a test name, for instance), that'd be best.