Re: [PATCH v4 2/2] scripts: generate_rust_analyzer.py: fix IDE support for primitive types

[Jesung Yang]

On Sat, Apr 25, 2026 at 3:27 PM Tamir Duberstein <tamird@xxxxxxxxxx> wrote:
> On 2026-04-25 12:17:04+00:00, Jesung Yang wrote:
> > On Thu, Mar 19, 2026 at 3:02 PM Tamir Duberstein <tamird@xxxxxxxxxx> wrote:
> > > On Tue, 17 Mar 2026 18:29:55 +0900, Jesung Yang <y.j3ms.n@xxxxxxxxx> wrote:
> > >
> > > This seems to be independent of the RA version. Is this broken today? Should it
> > > be a separate patch? Maybe that patch need not be in this series.
> >
> > The primary motivation for the versioning infrastructure was to
> > incorporate the `crate_attrs` feature introduced in the recent
> > rust-analyzer release (denoted as `RaVersionInfo.SUPPORTS_CRATE_ATTRS`
> > in our case).
> > This solves the side effect of enabling `sysroot_src`: `sysroot_src`
> > implicitly brings in `std` as a dependency, which is undesirable for
> > driver crates. Setting `crate_attrs=["no_std"]` is a direct fix for
> > this.
>
> I think I understand. Setting `crate_attrs=["no_std"]` is a no-op in the
> absence of `sysroot_src` but required for correct behavior in the
> presenve of `sysroot_src`. Do I have that right?

That's correct.

(Technically, the standalone `crate_attrs=["no_std"]` isn't a true
no-op, but you've got the idea; in our case it's effectively a no-op.)

> > I could split this series into two separate patches, but I prefer to
> > keep them in the same series. I think a standalone versioning
> > infrastructure patch would be unjustified in isolation without an actual
> > consumer of that logic.
> >
> > > Is this broken today?
> >
> > If we enable `sysroot_src` without `crate_attrs=["no_std"]`, users with
> > a fairly new rust-analyzer release would see, for example, auto-complete
> > suggestions for `std`.
> >
> > To provide full context, here is the sequence of issues:
> >
> >   1) Inherent impls for primitive type have been broken in recent
> >      rust-analyzer releases.
> >   2) To fix 1), we need to enable `sysroot_src`. There are also other
> >      reasons reported by Eliot to enable it, as we know.
> >   3) A new problem emerges: rust-analyzer thinks we have `std` in the
> >      kernel driver crates.
> >   4) To fix 3), we need to use `crate_attrs=["no_std"]` alongside
> >      `sysroot_src`.
> >   5) However, `crate_attrs` is only available in rust-analyzer>=0.3.2727.
> >   6) This means rust-analyzer<0.3.2727 would still suffer from 3) if we
> >      just use `sysroot_src` + `crate_attrs=["no_std"]`.
> >   7) We need an infrastructure to conditionally include both
> >      `sysroot_src` and `crate_attrs["no_std"]` based on the user's
> >      rust-analyzer version.
> >
> > I hope this clarifies the intent.
>
> Oh, this contradicts my understanding. Forgive me if I misunderstood,
> but aren't you populating `crate_attrs` above unconditionally? Unless by
> "only availble" you mean it is silently ignored by earlier versions? In
> that case this all makes sense.

The conditional guard actually lives in the first patch:

+        crate_attrs = (
+            crate_attrs if ctx.use_crate_attrs and crate_attrs is not
None else []
+        )

... and I don't understand why I bundled this into the first patch.

Apologies for the confusion, I'll move the logic related to
`use_crate_attrs` to this patch (i.e., [PATCH v4 2/2] scripts:
generate_rust_analyzer.py: fix IDE support for primitive types).

(As a side note: `crate_attrs` is indeed ignored by earlier versions,
but since this behavior is not publicly documented and is more of an
implementation detail, I'd prefer not to rely on it.)

> > > This bifurcates the handling of RA version differences: half of it is encoded
> > > in RaVersionCtx, and the other half is here in the presence or absence of
> > > "sysroot_src". Can we keep it somehow more contained?
> >
> > Fair point. Actually, the presence or absence of `sysroot_src` should
> > depend on `manual_sysroot_crates`. To keep things more self-contained,
> > I think it would be better to embed `RaVersionCtx` directly into
> > `RaVersionInfo`, since the values in `RaVersionCtx` are solely
> > determined by the version.
> >
> > I'm thinking of something like this:
> >
> > -------------------------------------------------
> > [...]
> > -------------------------------------------------
> >
> > This allows us to remove the if-else branches and the `assert_never`
> > check altogether.
>
> Looks reasonable to me. I'd rename DEFAULT to MSRV. Its value should be
> the new MSRV which is 1.85.0.

Thanks for the reminder!

Best regards,
Jesung