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

["Alexandre Courbot" <acourbot@nvidia.com>]

On Sun Nov 2, 2025 at 9:00 PM JST, Miguel Ojeda wrote:
> On Sun, Nov 2, 2025 at 3:25 AM Alexandre Courbot <acourbot@nvidia.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...

It does - thanks for taking the time to explain!

I'll leave the config option name as it currently then.