Skip to contentSkip to conversation

rust: kbuild: allow `unused_features`

PATCH Applied Miguel Ojeda 4 participants 4 messages Mar 12

Subsystems (3)
lore
Share & tools
lore

Miguel Ojeda

author maintainer
#0 lore raw

PATCH 1/1 rust: kbuild: allow `unused_features`

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.

---
 Makefile | 1 +
 1 file changed, 1 insertion(+)
Makefile +1 -0
index 73a39592f112..587345f16c97 100644
@@ -476,6 +476,7 @@ KBUILD_USERLDFLAGS := $(USERLDFLAGS)
 export rust_common_flags := --edition=2021 \
 			    -Zbinary_dep_depinfo=y \
 			    -Astable_features \
+			    -Aunused_features \
 			    -Dnon_ascii_idents \
 			    -Dunsafe_op_in_unsafe_fn \
 			    -Wmissing_docs \

base-commit: 487f9b3dc6e507a982f1b984aa6bfbd9dc4b0567

Signature · 1 line
2.53.0
reviewer Reviewed-by on v1 1/1
#1 lore raw
Quoted 36 lines · Miguel Ojeda

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.

Quoted 7 lines
Quoted 3 lines
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)
reviewer Reviewed-by on v1 1/1
#2 lore raw
In reply to Miguel Ojeda
Quoted 36 lines · Miguel Ojeda

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.

Quoted 7 lines
Quoted 18 lines
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)
Makefile +1 -0
index 73a39592f112..587345f16c97 100644
@@ -476,6 +476,7 @@ KBUILD_USERLDFLAGS := $(USERLDFLAGS)
 export rust_common_flags := --edition=2021 \
 			    -Zbinary_dep_depinfo=y \
 			    -Astable_features \
+			    -Aunused_features \
 			    -Dnon_ascii_idents \
 			    -Dunsafe_op_in_unsafe_fn \
 			    -Wmissing_docs \

base-commit: 487f9b3dc6e507a982f1b984aa6bfbd9dc4b0567

Applied
#3 lore raw
In reply to Miguel Ojeda
Quoted 37 lines · Miguel Ojeda

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.

Quoted 7 lines

Applied to rust-fixes -- thanks everyone!

We were already discussing this in the links above, and it is fairly trivial on our side, so I am putting it in already so that it goes into the next fixes PR.

Cheers,
Miguel