Repository navigation
We should reject #[test] and cfg(test) in core #163045
Description
#[test] functions should not go in library/core, because they are not actually run. The crate library/coretests exists for this purpose instead. cfg(test) is similarly suspicious, because core doesn't end up being built under that cfg when running ./x.py test library.
We should have a lint against both of these constructs. It may also be desirable to lint in alloc and std, but there's significant use of the cfg in those crates, so presumably they're doing something.
This was discovered in practice due to the use of #[cfg(test)] in library/core/cell/covariant_unsafe_cell.rs causing CovariantUnsafeCell's variance to not actually be tested.
Reacted by Max, Roland Xu and teor
Activity
asquared31415 commentedon Sep 20, 2026
theemathas commentedon Sep 20, 2026
Github search for instances of this: https://github.com/search?q=repo%3Arust-lang%2Frust+path%3Alibrary%2Fcore%2F+%2Fcfg.*test%2F&type=code
theemathas commentedon Sep 20, 2026
#160687 (comment) added the following comment
cc @bushrat011899
zachs18 commentedon Sep 21, 2026
Hmm, under bare
rustc,rustc --check-cfg 'cfg()'warns oncfg(test), socargois passing--check-cfg 'cfg(test)'.Ah, cargo had logic to mark
testas an (un)expected cfg based on[lib] test = falseinCargo.toml(PR), but it wasn't clear exactly whattest = falseshould mean, so the logic was reverted (PR), so currentlytestis always treated as expected. See this cargo issue for discussionRollup merge of rust-lang#163051 - asquared31415:actually_covariant_u…
bushrat011899 commentedon Sep 22, 2026
Yeah I think this should be looked at in much more detail before rejecting
cfg(test)/cfg(not(test))incore. While it's specific tosplat, clearlycfg(not(test))does do something, even if it's not well understood or intended.asquared31415 commentedon Sep 22, 2026
I think that as long as the mechanism had a "i know what im doing" button, we could apply the restriction generally. The target audience for this is rustc internals, it can be a little rough. We just want to stop the people that assume "the test infrastructure works normally in core", and having to say the "i know what im doing" incantation would be enough friction IMO.
asquared31415 commentedon Sep 22, 2026
The rustc dev guide says
During the initial implementation of diagnostic items, this pattern was also used, so this is definitely a known weirdness. Maybe we could have an exception for diagnostic items specifically? There's so few in core though, that I would be fine with case-by-case manual exceptions.
Other than the diagnostics items though, there's a little bit of
f16andf128code, and then the splat weirdness. All of these seem strange enough to me that it would be helpful to have a "i know what im doing, and here's why this is needed" (or i don't know why this is broken but it fixes it, put in a FIXME)asquared31415 commentedon Sep 22, 2026
Also this is all under the assumption that core cannot be built under the normal testing machinery for some reason. If someone figures out "oh we can just tweak a flag and it all works perfectly" then that would be great, and we wouldn't need to reject use of
cfg(test).Unrolled build for #163051 in rollup 163139
bjorn3 commentedon Sep 22, 2026
With a bunch of
cfgto remove all lang items it technically can be, but we still shouldn't put tests in the same package as any standard library crate. The problem with that setup is that thecargo buildfor building the standard library andcargo testfor testing need to use the exact same flags to prevent standard library crates getting duplicated between regular deps and libtest deps. That is why I also moved all liballoc tests into a separate crate and want to move all other tests out into separate packages.