linux-kernel - Re: [PATCH RESEND] rust: enable slice_flatten feature and abstract it through an extension trait

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: <CANiq72nakhVrfK=pyz8VBo95NJHpoeDXRkqUBc4GXSdroYuAQQ@mail.gmail.com>
Date: Sun, 2 Nov 2025 13:00:38 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Alexandre Courbot <acourbot@...dia.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, Nathan Chancellor <nathan@...nel.org>, 
	Nicolas Schier <nicolas.schier@...ux.dev>, linux-kernel@...r.kernel.org, 
	rust-for-linux@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH RESEND] rust: enable slice_flatten feature and abstract it
 through an extension trait

On Sun, Nov 2, 2025 at 3:25 AM Alexandre Courbot <acourbot@...dia.com> wrote:
>
> Also not all of these seem to be tied to a feature;
> `RUSTC_HAS_FILE_AS_C_STR` appears to refer to the
> `Location::file_as_c_str` method, which is behind the `file_with_nul`
> feature.

So what happens there is that there are 3 states: "not implemented",
"unstable" and "unstable but changed". That is, one transition is when
the stdlib added it and the other when it changed.

Now, normally there are only 2: "not implemented" and "unstable", and
thus using the feature name makes sense there, because we use the
Kconfig symbol to enable the feature conditionally, not individual
methods (and a feature may contain different methods or even language
features etc.).

There is also the "stable" state of course -- the features don't get
removed internally when stabilized, and in fact there is a lint that
tells you about it (using that information), but we allow it, so it
all works without extra complexity.

In this case, we have 2 states but the other ones: "unstable" and
"unstable but changed", because `slice_flatten` exists for way longer
than our MSRV. And for this transition, for the other feature, we used
the renamed method name, which makes sense since that is what got
renamed, e.g. it could happen that a feature has 10 methods, and 2 get
renamed in version X.

So I think what you have in your patch actually makes more sense,
since you are in the rename transition, not the feature addition one
(i.e. we unconditionally enable `slice_flatten`).

I guess we could come up with a different naming scheme to distinguish
both cases or similar. For instance, we could add `FEATURE_` to the
cases of the first transition. Anyway, it is not a big deal since we
don't expect to have a ton of these -- quite the opposite, hopefully
we can get rid them soon. And I wouldn't invert the logic of those
equations, I think that gets even more confusing.

So apologies for the noise there :) At least I hope it clarifies a bit...

Cheers,
Miguel