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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH5fLgi1_=FhM1800xz=53OpfvF55WqBijPSvSXC7pHuFL41rA@mail.gmail.com>
Date: Tue, 27 Aug 2024 13:30:29 +0200
From: Alice Ryhl <aliceryhl@...gle.com>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Wedson Almeida Filho <wedsonaf@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Andreas Hindborg <a.hindborg@...sung.com>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH] rust: allow `stable_features` lint

On Tue, Aug 27, 2024 at 1:29 PM Benno Lossin <benno.lossin@...ton.me> wrote:
>
> On 27.08.24 12:39, Alice Ryhl wrote:
> > On Tue, Aug 27, 2024 at 12:04 PM Miguel Ojeda <ojeda@...nel.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ