The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Miguel Ojeda <ojeda@kernel.org>
To: Miguel Ojeda <ojeda@kernel.org>,
	Alex Gaynor <alex.gaynor@gmail.com>,
	Wedson Almeida Filho <wedsonaf@gmail.com>
Cc: "Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@samsung.com>,
	"Alice Ryhl" <aliceryhl@google.com>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	patches@lists.linux.dev
Subject: [PATCH] rust: allow `stable_features` lint
Date: Tue, 27 Aug 2024 12:04:03 +0200	[thread overview]
Message-ID: <20240827100403.376389-1-ojeda@kernel.org> (raw)

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@kernel.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

             reply	other threads:[~2024-08-27 10:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-27 10:04 Miguel Ojeda [this message]
2024-08-27 10:39 ` [PATCH] rust: allow `stable_features` lint Alice Ryhl
2024-08-27 11:29   ` Benno Lossin
2024-08-27 11:30     ` Alice Ryhl
2024-08-28  9:39 ` Miguel Ojeda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240827100403.376389-1-ojeda@kernel.org \
    --to=ojeda@kernel.org \
    --cc=a.hindborg@samsung.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=wedsonaf@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox