linux-kernel - [PATCH] rust: allow `stable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240827100403.376389-1-ojeda@kernel.org>
Date: Tue, 27 Aug 2024 12:04:03 +0200
From: Miguel Ojeda <ojeda@...nel.org>
To: Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Wedson Almeida Filho <wedsonaf@...il.com>
Cc: Boqun Feng <boqun.feng@...il.com>,
	Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...sung.com>,
	Alice Ryhl <aliceryhl@...gle.com>,
	rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	patches@...ts.linux.dev
Subject: [PATCH] rust: allow `stable_features` lint

Support for several Rust compiler versions started in commit 63b27f4a0074
("rust: start supporting several compiler versions"). Since we currently
need to use a number of unstable features in the kernel, it is a matter
of time until one gets stabilized and the `stable_features` lint warns.

For instance, the `new_uninit` feature may become stable soon, which
would give us multiple warnings like the following:

    warning: the feature `new_uninit` has been stable since 1.82.0-dev
    and no longer requires an attribute to enable
      --> rust/kernel/lib.rs:17:12
       |
    17 | #![feature(new_uninit)]
       |            ^^^^^^^^^^
       |
       = note: `#[warn(stable_features)]` on by default

Thus allow the `stable_features` lint to avoid such warnings. This is
the simplest approach -- we do not have that many cases (and the goal
is to stop using unstable features anyway) and cleanups can be easily
done when we decide to update the minimum version.

An alternative would be to conditionally enable them based on the
compiler version (with the upcoming `RUSTC_VERSION` or maybe with the
unstable `cfg(version(...))`, but that one apparently will not work for
the nightly case). However, doing so is more complex and may not work
well for different nightlies of the same version, unless we do not care
about older nightlies.

Another alternative is using explicit tests of the feature calling
`rustc`, but that is also more complex and slower.

Signed-off-by: Miguel Ojeda <ojeda@...nel.org>
---
I may take this through `rust-fixes` too, since it is straightfoward and
it could help some developers/CIs if something gets stabilized soon.

 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 68ebd6d6b444..cf1111476f46 100644
--- a/Makefile
+++ b/Makefile
@@ -445,6 +445,7 @@ KBUILD_USERLDFLAGS := $(USERLDFLAGS)
 # host programs.
 export rust_common_flags := --edition=2021 \
 			    -Zbinary_dep_depinfo=y \
+			    -Astable_features \
 			    -Dunsafe_op_in_unsafe_fn \
 			    -Dnon_ascii_idents \
 			    -Wrust_2018_idioms \
--
2.46.0