]> www.infradead.org Git - users/jedix/linux-maple.git/commit
rust: allow `stable_features` lint
authorMiguel Ojeda <ojeda@kernel.org>
Tue, 27 Aug 2024 10:04:03 +0000 (12:04 +0200)
committerMiguel Ojeda <ojeda@kernel.org>
Tue, 27 Aug 2024 20:50:09 +0000 (22:50 +0200)
commit8e95e53ca379a03d7f5bfc567a610baa85e15424
treed56e3f5c2242c21e0de957fdaff7421b6b708ecd
parent7d2fc5a4038df307393769e198a8b1bf189fd6e5
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.

Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240827100403.376389-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Makefile