Re: [PATCH v2 5/5] rust: enable `clippy::as_underscore` lint

[Benno Lossin <benno.lossin@proton.me>]

On Thu Mar 13, 2025 at 6:50 PM CET, Tamir Duberstein wrote:
> On Thu, Mar 13, 2025 at 10:11 AM Benno Lossin <benno.lossin@proton.me> wrote:
>>
>> On Thu Mar 13, 2025 at 11:47 AM CET, Tamir Duberstein wrote:
>> > On Wed, Mar 12, 2025 at 6:38 PM Benno Lossin <benno.lossin@proton.me> wrote:
>> >>
>> >> On Wed Mar 12, 2025 at 11:24 PM CET, Tamir Duberstein wrote:
>> >> > On Wed, Mar 12, 2025 at 5:30 PM Benno Lossin <benno.lossin@proton.me> wrote:
>> >> >>
>> >> >> On Wed Mar 12, 2025 at 10:10 PM CET, Tamir Duberstein wrote:
>> >> >> > On Wed, Mar 12, 2025 at 5:04 PM Tamir Duberstein <tamird@gmail.com> wrote:
>> >> >> >>
>> >> >> >> On Wed, Mar 12, 2025 at 5:01 PM Benno Lossin <benno.lossin@proton.me> wrote:
>> >> >> >> > Always enable the features, we have `allow(stable_features)` for this
>> >> >> >> > reason (then you don't have to do this dance with checking if it's
>> >> >> >> > already stable or not :)
>> >> >> >>
>> >> >> >> It's not so simple. In rustc < 1.84.0 the lints *and* the strict
>> >> >> >> provenance APIs are behind `feature(strict_provenance)`. In rustc >=
>> >> >> >> 1.84.0 the lints are behind `feature(strict_provenance_lints)`. So you
>> >> >> >> need to read the config to learn that you need to enable
>> >> >> >> `feature(strict_provenance_lints)`.
>> >> >>
>> >> >> I see... And `strict_provenance_lints` doesn't exist in <1.84? That's a
>> >> >> bit of a bummer...
>> >> >>
>> >> >> But I guess we could have this config option (in `init/Kconfig`):
>> >> >>
>> >> >>     config RUSTC_HAS_STRICT_PROVENANCE
>> >> >>             def_bool RUSTC_VERSION >= 108400
>> >> >>
>> >> >> and then do this in `lib.rs`:
>> >> >>
>> >> >>     #![cfg_attr(CONFIG_RUSTC_HAS_STRICT_PROVENANCE, feature(strict_provenance_lints))]
>> >> >
>> >> > Yep! That's exactly what I did, but as I mentioned up-thread, the
>> >> > result is that we only cover the `kernel` crate.
>> >>
>> >> Ah I see, can't we just have the above line in the other crate roots?
>> >
>> > The most difficult case is doctests. You'd have to add this to every
>> > example AFAICT.
>> >
>> >> >> > Actually this isn't even the only problem. It seems that
>> >> >> > `-Astable_features` doesn't affect features enabled on the command
>> >> >> > line at all:
>> >> >> >
>> >> >> > error[E0725]: the feature `strict_provenance` is not in the list of
>> >> >> > allowed features
>> >> >> >  --> <crate attribute>:1:9
>> >> >> >   |
>> >> >> > 1 | feature(strict_provenance)
>> >> >> >   |         ^^^^^^^^^^^^^^^^^
>> >> >>
>> >> >> That's because you need to append the feature to `rust_allowed_features`
>> >> >> in `scripts/Makefile.build` (AFAIK).
>> >> >
>> >> > Thanks, that's a helpful pointer, and it solves some problems but not
>> >> > all. The root Makefile contains this bit:
>> >> >
>> >> >> KBUILD_HOSTRUSTFLAGS := $(rust_common_flags) -O -Cstrip=debuginfo \
>> >> >> -Zallow-features= $(HOSTRUSTFLAGS)
>> >> >
>> >> > which means we can't use the provenance lints against these host
>> >> > targets (including e.g. `rustdoc_test_gen`). We can't remove this
>> >> > -Zallow-features= either because then core fails to compile.
>> >> >
>> >> > I'm at the point where I think I need more involved help. Want to take
>> >> > a look at my attempt? It's here:
>> >> > https://github.com/tamird/linux/tree/b4/ptr-as-ptr.
>>
>> With doing `allow(clippy::incompatible_msrv)`, I meant doing that
>> globally, not having a module to re-export the functions :)
>
> Yeah, but I think that's too big a hammer. It's a useful warning, and
> it doesn't accept per-item configuration.

Hmm, I don't think it's as useful. We're going to be using more unstable
features until we eventually bump the minimum version when we can
disable `RUSTC_BOOTSTRAP=1`. From that point onwards, it will be very
useful, but before that I don't think that it matters too much. Maybe
the others disagree.

>> >> I'll take a look tomorrow, you're testing my knowledge of the build
>> >> system a lot here :)
>> >
>> > We're guaranteed to learn something :)
>>
>> Yep! I managed to get it working, but it is rather janky and
>> experimental. I don't think you should use this in your patch series
>> unless Miguel has commented on it.
>>
>> Notable things in the diff below:
>> * the hostrustflags don't get the *provenance_casts lints (which is
>>   correct, I think, but probably not the way I did it with filter-out)
>> * the crates compiler_builtins, bindings, uapi, build_error, libmacros,
>>   ffi, etc do get them, but probably shouldn't?
>
> Why don't we want host programs to have the same warnings applied? Why
> don't we want it for all those other crates?

I have never looked at the rust hostprogs before, so I'm missing some
context here.

I didn't enable them, because they are currently being compiled without
any unstable features and I thought we might want to keep that. (though
I don't really see a reason not to compile them with unstable features
that we also use for the kernel crate)

> I'd expect we want uniform diagnostics settings throughout which is
> why these things are in the Makefile rather than in individual crates
> in the first place.
>
> Your patch sidesteps the problems I'm having by not applying these
> lints to host crates, but I think we should.

We're probably working on some stuff that Miguel's new build system will
do entirely differently. So I wouldn't worry too much about getting it
perfect, as it will be removed in a couple cycles.

---
Cheers,
Benno