Conversation
The `unused_features` lint was introduced in [1], presumably landing in Rust 1.96.0. We simplified the way we use features in #102, always enabling them when building the crate with certain features enabled. For this reason allow the lint. Link: rust-lang/rust#152164 [1] Signed-off-by: Benno Lossin <lossin@kernel.org>
nbdd0121
left a comment
There was a problem hiding this comment.
We would also need to enable this in general for other kernel crates, I think?
|
Yes, I already notified Miguel (although in the kernel it only is a warning as opposed to here where it is an error due to our |
|
There's CONFIG_WERROR so it's also problematic |
|
Yeah, e.g. from one of my builds: I will put a workaround for rust.docs.kernel.org for now. |
|
I tried to set up a CI check, but it didn't work, since the |
|
For Linux, I am also hitting: I think it is simpler for us to simply allow it globally because one way or the other we will hit it. |
|
Did you try it with a nightly that includes the fix for rust-lang/rust#153523? It might go away with that (at least for some builds, we probably still end up with |
|
But, yeah, I tested with the latest nightly, which already includes the fix. And, yeah, conditional compilation (and generally compiling crates that may not use a particular feature) will likely be an issue. |
|
I mean, we could require crates to enable features manually (even if we still only allow those to be enabled via |
Starting with the upcoming Rust 1.96.0 (to be released 2026-05-28),
`rustc` introduces the new lint `unused_features` [1], which warns [2]:
warning: feature `used_with_arg` is declared but not used
--> <crate attribute>:1:93
|
1 | #![feature(asm_const,asm_goto,arbitrary_self_types,lint_reasons,offset_of_nested,raw_ref_op,used_with_arg)]
| ^^^^^^^^^^^^^
|
= note: `#[warn(unused_features)]` (part of `#[warn(unused)]`) on by default
The original goal of using `-Zcrate-attr` automatically was that there
is a consistent set of features enabled and managed globally for all
Rust kernel code (modulo exceptions like the `rust/` crated).
While we could require crates to enable features manually (even if we
still keep the `-Zallow-features=` list, i.e. removing the `-Zcrate-attr`
list), it is not really worth making all developers worry about it just
for a new lint.
The features are expected to eventually become stable anyway (most already
did), and thus having to remove features in every file that may use them
is not worth it either.
Thus just allow the new lint globally.
The lint actually existed for a long time, which is why `rustc` does
not complain about an unknown lint in the stable versions we support,
but it was "disabled" years ago [3], and now it was made to work again.
For extra context, the new implementation of the lint has already been
improved to avoid linting about features that became stable thanks to
Benno's report and the ensuing discussion [4] [5], but while that helps,
it is still the case that we may have features enabled that are not used
for one reason or another in a particular crate.
Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: rust-lang/rust#152164 [1]
Link: Rust-for-Linux/pin-init#114 [2]
Link: rust-lang/rust#44232 [3]
Link: rust-lang/rust#153523 [4]
Link: rust-lang/rust#153610 [5]
Reviewed-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260312111014.74198-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The
unused_featureslint was introduced in rust-lang/rust#152164, presumably landing in Rust 1.96.0. We simplified the way we use features in #102, always enabling them when building the crate with certain features enabled. For this reason allow the lint.I plan to also add a new CI run that enables the lint & checks if we can remove certain features. Will do so at a later point in time.
This PR fixes the CI failure observed in https://github.com/Rust-for-Linux/pin-init/actions/runs/22754182535