Re: [PATCH v7 2/2] scripts: generate_rust_analyzer.py: fix IDE support for primitive types
From: Tamir Duberstein
Date: Mon May 11 2026 - 14:12:04 EST
On Thu, May 7, 2026 at 10:47 AM Jesung Yang via B4 Relay
<devnull+y.j3ms.n.gmail.com@xxxxxxxxxx> wrote:
>
> From: Jesung Yang <y.j3ms.n@xxxxxxxxx>
>
> Update `generate_rust_analyzer.py` so that the generated
> `rust-project.json` contains the `sysroot_src` field with
> `"crate_attrs": ["no_std"]` specified for relevant crates. This ensures
> that rust-analyzer provides proper IDE support for inherent methods of
> primitive types.
>
> Since commit 50384460c68f ("Rewrite method resolution to follow rustc
> more closely") to rust-analyzer, it no longer provides language server
> features like code completion and go-to-definition for inherent methods
> of primitive types when sysroot crates (e.g., `core`, `std`) are inlined
> in `rust-project.json` [1]. As `generate_rust_analyzer.py` currently
> inlines these crates, our setup is affected by this change.
>
> Specifying the `sysroot_src` field restores this functionality by
> allowing rust-analyzer to locate sysroot crates by itself. However, this
> causes `std` to be treated as a dependency for all local crates by
> default. To align with our compilation settings, provide the `no_std`
> attribute via the `crate_attrs` field, as the `-Zcrate-attr=no_std`
> compiler flag is not visible to rust-analyzer. This combined approach
> removes manual manipulation of sysroot dependencies while preventing
> incorrect symbol resolution against the standard library.
>
> Note that this configuration requires rust-analyzer release 2025-12-22
> (v0.3.2727) or later, which introduced support for the `crate_attrs`
> field.
>
> Link: https://rust-lang.zulipchat.com/#narrow/channel/x/topic/x/near/561607963 [1]
> Link: https://rust-for-linux.zulipchat.com/#narrow/channel/x/topic/x/near/561607753
> Reviewed-by: Tamir Duberstein <tamird@xxxxxxxxxx>
> Signed-off-by: Jesung Yang <y.j3ms.n@xxxxxxxxx>
I think this loses the kernel's custom sysroot crate cfgs. In particular,
rust/Makefile passes --cfgs='core=$(core-cfgs)' today, which includes
no_fp_fmt_parse. Once we switch to sysroot_src and stop modeling core
explicitly, rust-analyzer discovers core by itself and no longer sees those
cfgs.
Would sysroot_project be needed here to keep the custom sysroot crate
configuration while still avoiding the primitive-method resolution issue?