Re: [PATCH 6/6] scripts: generate_rust_analyzer: move sysroot crates to sysroot_project

["Eliot Courtney" <ecourtney@nvidia.com>]

On Thu Jan 22, 2026 at 8:06 PM JST, Jesung Yang wrote:
> On Thu Jan 22, 2026 at 6:23 PM KST, Eliot Courtney wrote:
>> On Wed Jan 21, 2026 at 9:01 AM JST, Jesung Yang wrote:
>>> I still think the versioning infrastructure is a prerequisite as we're
>>> using the `sysroot_src` field here.
>>>
>>> If we specify `sysroot_src` without `crate_attrs = ["no_std"]`,
>>> rust-analyzer treats `std` as a dependency for all local crates by
>>> default. Consequently, any rust-analyzer version lacking `crate_attrs`
>>> support (which silently ignores `crate_attrs = ["no_std"]`) would
>>> incorrectly assume an implicit `std` dependency for all kernel modules.
>>> Having the versioning infrastructure first allows us to handle this
>>> transition without breaking the user experience for those on older
>>> toolchains.
>> Yeah, I agree that specifying sysroot_src by itself includes std and that
>> is potentially an issue.
>>
>> But, currently due to issues like the relative #[path] include, the
>> sysroot crates aren't really processable very well by rust-analyzer
>> causing a lot of spurious errors and unresolved symbols, which make
>> using the LSP experience pretty bad IMO. OTOH, while the sysroot_src
>> approach does include std, it at least makes it usable. Personally I
>> find it more useful this way, but I can see the argument for both sides.
>
> So the problem here is that the versioning infrastructure effectively
> restricts the use of `sysroot_src` for older rust-analyzer versions
> that do not support `crate_attrs`, which leads to yet another bad
> experience. Hmm... I would like to hear others' thoughts on this
> trade-off, since I don't have a perfect solution at the moment.

I think it's possible to get it to work (at least better - not sure if
it fully fixes all issues) in RA 1.78.0 without specifying sysroot_src
if we add include_dirs to allow the relative #[path] references to be
resolved.

> On a separate note: I actually have a previous effort covering
> `sysroot_src` and `crate_attrs` [2] that I'd like to land first. It
> covers almost the same ground as your 6th patch (minus the
> `sysroot_project` use). Since I wrote the `crate-attrs` code in
> rust-analyzer itself specifically to improve its usability in the
> kernel, I'm hoping to finish the full story on the kernel side. Would
> you be open to that?

Yes, of course, please feel free to land whatever you want. I'm sorry I
didn't notice this, I think I only searched for rust[-_]analyzer in the
subject line when I was checking the existing state. I'm still working
out my workflow and how to avoid missing things like this, so I
appreciate your patience. If there's anything useful from my patch
series I can send a v2 if you would like, or I can rebase it on top of
some other patch series, or not.

Thanks~

>
> Thanks!
>
> [1] https://rust-for-linux.zulipchat.com/#narrow/channel/x/topic/x/near/561668361
> [2] https://lore.kernel.org/rust-for-linux/20260101-ra-fix-primitive-v1-1-def809357b4e@gmail.com/
>
> Best regards,
> Jesung