[PATCH] rust: allow `stable_features` lint

[PATCH] rust: allow `stable_features` lint

[Miguel Ojeda]

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

Re: [PATCH] rust: allow `stable_features` lint

[Alice Ryhl]

On Tue, Aug 27, 2024 at 12:04 PM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> 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.

You mention a bunch of alternatives, but I agree that this is the best
way forward. It's very simple. Only possible disadvantage could be if
we forget to remove features when raising the MSRV, but I don't think
that's a big risk.

(You could potentially pass -Astable_features only when the Rust
compiler is not the lowest supported version.)

> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

Re: [PATCH] rust: allow `stable_features` lint

[Benno Lossin]

On 27.08.24 12:39, Alice Ryhl wrote:
> On Tue, Aug 27, 2024 at 12:04 PM Miguel Ojeda <ojeda@kernel.org> wrote:
>>
>> 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.
> 
> You mention a bunch of alternatives, but I agree that this is the best
> way forward. It's very simple. Only possible disadvantage could be if
> we forget to remove features when raising the MSRV, but I don't think
> that's a big risk.

What even are the risks associated with enabling an already stable
feature?

---
Cheers,
Benno

Re: [PATCH] rust: allow `stable_features` lint

[Alice Ryhl]

On Tue, Aug 27, 2024 at 1:29 PM Benno Lossin <benno.lossin@proton.me> wrote:
>
> On 27.08.24 12:39, Alice Ryhl wrote:
> > On Tue, Aug 27, 2024 at 12:04 PM Miguel Ojeda <ojeda@kernel.org> wrote:
> >>
> >> 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.
> >
> > You mention a bunch of alternatives, but I agree that this is the best
> > way forward. It's very simple. Only possible disadvantage could be if
> > we forget to remove features when raising the MSRV, but I don't think
> > that's a big risk.
>
> What even are the risks associated with enabling an already stable
> feature?

Nothing, really. Clutter?

Alice

Re: [PATCH] rust: allow `stable_features` lint

[Miguel Ojeda]

On Tue, Aug 27, 2024 at 12:04 PM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> 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>

Applied to `rust-fixes` -- thanks everyone!

Cheers,
Miguel