linux-kernel - Re: [PATCH 6/6] scripts: generate_rust_analyzer: move sysroot crates to sysroot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72n65eLUmWShvpVBzkbCork_85A8nMZPKdf+rpw-nJ6j_Q@mail.gmail.com>
Date: Fri, 23 Jan 2026 13:08:06 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Eliot Courtney <ecourtney@...dia.com>
Cc: Jesung Yang <y.j3ms.n@...il.com>, Tamir Duberstein <tamird@...nel.org>, 
	Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nsc@...nel.org>, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-kbuild@...r.kernel.org
Subject: Re: [PATCH 6/6] scripts: generate_rust_analyzer: move sysroot crates
 to sysroot_project

On Fri, Jan 23, 2026 at 6:45 AM Eliot Courtney <ecourtney@...dia.com> wrote:
>
> 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.

Generally speaking, if a version of rust-analyzer is complex to
support , then it may be best to consider avoid supporting it.

It is an optional development tool and many/most use the latest
version and/or the distro-provided one. Plus we will be moving to the
new minimum soon, and so far we didn't support multi-version for the
tool anyway.

So, in general, if it is something trivial to support, then why not.
Otherwise, I would recommend focusing the support on Rust 1.85 and
later (especially the latest plus versions in popular distributions).

And if a good test can be done in CI for the new multi-version support
etc., then it may make sense to test nightly and things like that too,
and even ask upstream if they would like to add the test in their CI,
like we do for the compiler and bindgen.

Thanks!

Cheers,
Miguel