Makefile | 8 ++++++++ 1 file changed, 8 insertions(+)
Sometimes it is useful to gate global Rust flags per compiler version.
For instance, we may want to disable a lint that has false positives in
a single version [1].
We already had helpers like `rustc-min-version` for that, which we use
elsewhere, but we cannot currently use them for `rust_common_flags`,
which contains the global flags for all Rust code (kernel and host),
because `rustc-min-version` depends on `CONFIG_RUSTC_VERSION`, which
does not exist when `rust_common_flags` is defined.
Thus, to support that, introduce `rust_common_flags_per_version`,
defined after the `include/config/auto.conf` inclusion (where
`CONFIG_RUSTC_VERSION` becomes available), and append it to
`rust_common_flags`, `KBUILD_HOSTRUSTFLAGS` and `KBUILD_RUSTFLAGS`.
An alternative is moving all those three down, but that would mean
separating them from the other `KBUILD_*` variables.
Link: https://lore.kernel.org/rust-for-linux/CANiq72mWdFU11GcCZRchzhy0Gi1QZShvZtyRkHV2O+WA2uTdVQ@mail.gmail.com/ [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
> Doing it globally for certain versions (i.e. `rust_common_flags`, not
> just `KBUILD_RUSTFLAGS`) requires a bit of reorganization,
If we wanted to go for a per-version global one, we we would need
something like this patch -- sending it here so that it gets archived
in case we need it.
Makefile | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Makefile b/Makefile
index 2446085983f7..a49cddb0599b 100644
--- a/Makefile
+++ b/Makefile
@@ -833,6 +833,14 @@ endif # CONFIG_TRACEPOINTS
export WARN_ON_UNUSED_TRACEPOINTS
+# Per-version Rust flags. These are like `rust_common_flags`, but may
+# depend on the Rust compiler version (e.g. using `rustc-min-version`).
+rust_common_flags_per_version :=
+
+rust_common_flags += $(rust_common_flags_per_version)
+KBUILD_HOSTRUSTFLAGS += $(rust_common_flags_per_version)
+KBUILD_RUSTFLAGS += $(rust_common_flags_per_version)
+
include $(srctree)/arch/$(SRCARCH)/Makefile
ifdef need-config
base-commit: 11439c4635edd669ae435eec308f4ab8a0804808
--
2.53.0On Sat, Mar 7, 2026 at 6:09 PM Miguel Ojeda <ojeda@kernel.org> wrote: > > Sometimes it is useful to gate global Rust flags per compiler version. > For instance, we may want to disable a lint that has false positives in > a single version [1]. Regarding this, we currently have a warning on 1.85.1 for `clippy::precedence` and a few in 1.88.0 for `clippy::uninlined_format_args`, so we could use this to sort those out (plus `clippy::double_parens` for 1.92.0). (We will see how hard it is to keep all these versions clean in the medium-term future when more Rust is in the kernel: we have the MSRV bump cadence now with Debian Stable, so it may be doable, but worst case we could consider relaxing the policy to just the latest stable release and whatever linux-next runs). Cheers, Miguel
On Sun, Mar 15, 2026 at 10:21:04PM +0100, Miguel Ojeda wrote: > (We will see how hard it is to keep all these versions clean in the > medium-term future when more Rust is in the kernel: we have the MSRV > bump cadence now with Debian Stable, so it may be doable, but worst > case we could consider relaxing the policy to just the latest stable > release and whatever linux-next runs). At the minute whatever linux-next runs is whatever Debian stable has!
On Mon, Mar 16, 2026 at 1:04 AM Mark Brown <broonie@kernel.org> wrote: > > At the minute whatever linux-next runs is whatever Debian stable has! Great, that would mean we are effectively keeping the minimum one clean, which is in a way the best we can do (apart from the maximum) if we don't try to keep every single version clean between them. It is also what we have asked patch submitters to do so far, i.e. to keep things clean for both the minimum and the maximum: https://rust-for-linux.com/contributing#submit-checklist-addendum Thanks for confirming! Cheers, Miguel
On Mon, Mar 16, 2026 at 05:49:02AM +0100, Miguel Ojeda wrote:
> On Mon, Mar 16, 2026 at 1:04 AM Mark Brown <broonie@kernel.org> wrote:
> > At the minute whatever linux-next runs is whatever Debian stable has!
> Great, that would mean we are effectively keeping the minimum one
> clean, which is in a way the best we can do (apart from the maximum)
> if we don't try to keep every single version clean between them.
Note that I've not started running with clippy yet, currently due to
Linus' tree having:
error: current MSRV (Minimum Supported Rust Version) is `1.78.0` but this item is stable since `1.79.0`
--> /tmp/next/build/rust/kernel/ptr/projection.rs:79:26
|
79 | if self >= slice.len() {
| ^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#incompatible_msrv
= note: `-D clippy::incompatible-msrv` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::incompatible_msrv)]`
error: current MSRV (Minimum Supported Rust Version) is `1.78.0` but this item is stable since `1.79.0`
--> /tmp/next/build/rust/kernel/ptr/projection.rs:95:29
|
95 | if self.end > slice.len() {
| ^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#incompatible_msrv
error: current MSRV (Minimum Supported Rust Version) is `1.78.0` but this item is stable since `1.79.0`
--> /tmp/next/build/rust/kernel/ptr/projection.rs:121:28
|
121 | (self.start..slice.len()).get(slice)
| ^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#incompatible_msrv
error: current MSRV (Minimum Supported Rust Version) is `1.78.0` but this item is stable since `1.79.0`
--> /tmp/next/build/rust/kernel/ptr.rs:253:11
|
253 | p.len() * size_of::<T>()
| ^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#incompatible_msrv
error: aborting due to 4 previous errors
On Mon, Mar 16, 2026 at 1:50 PM Mark Brown <broonie@kernel.org> wrote: > > Note that I've not started running with clippy yet, currently due to > Linus' tree having: > > error: current MSRV (Minimum Supported Rust Version) is `1.78.0` but this item is stable since `1.79.0` This was fixed in upstream Clippy in Rust 1.90.0 due to a request we made (thanks to Tamir): https://github.com/rust-lang/rust-clippy/issues/14425 I would suggest to allow the lint locally (perhaps once at the top of the file). This will go away this cycle since I am going to bump the minimum version to Debian Trixie's. Alternatively, we could use the patch above to add `clippy::incompatible_msrv`, but that is more involved, and allowing it locally is what we did elsewhere too. Cheers, Miguel
On Mon Mar 16, 2026 at 1:50 PM CET, Mark Brown wrote:
> On Mon, Mar 16, 2026 at 05:49:02AM +0100, Miguel Ojeda wrote:
>> On Mon, Mar 16, 2026 at 1:04 AM Mark Brown <broonie@kernel.org> wrote:
>
>> > At the minute whatever linux-next runs is whatever Debian stable has!
>
>> Great, that would mean we are effectively keeping the minimum one
>> clean, which is in a way the best we can do (apart from the maximum)
>> if we don't try to keep every single version clean between them.
>
> Note that I've not started running with clippy yet, currently due to
> Linus' tree having:
>
> error: current MSRV (Minimum Supported Rust Version) is `1.78.0` but this item is stable since `1.79.0`
> --> /tmp/next/build/rust/kernel/ptr/projection.rs:79:26
> |
> 79 | if self >= slice.len() {
> | ^^^^^
> |
> = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#incompatible_msrv
> = note: `-D clippy::incompatible-msrv` implied by `-D warnings`
> = help: to override `-D warnings` add `#[allow(clippy::incompatible_msrv)]`
Interesting, I neither see this with 1.78.0 nor 1.94.0, but I can indeed
reproduce this with 1.85.1.
© 2016 - 2026 Red Hat, Inc.