[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ-ks9nfMiizMAAnybtY2k5bUf5dsc4bzA__gpa_hq5NP7kxGw@mail.gmail.com>
Date: Fri, 16 Jan 2026 10:38:51 -0500
From: Tamir Duberstein <tamird@...nel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Gary Guo <gary@...yguo.net>, Jesung Yang <y.j3ms.n@...il.com>,
Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
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>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scripts: generate_rust_analyzer: compile sysroot with
correct edition
On Fri, Jan 16, 2026 at 9:43 AM Miguel Ojeda
<miguel.ojeda.sandonis@...il.com> wrote:
>
> On Fri, Jan 16, 2026 at 3:03 PM Tamir Duberstein <tamird@...nel.org> wrote:
> >
> > On Fri, Jan 16, 2026 at 6:53 AM Gary Guo <gary@...yguo.net> wrote:
> > >
> > > We don't build std nor proc-macro ourselves in rust/Makefile, so I don't think
> > > this should got there.
> > >
> > > I wonder if we should encode the fact about Rust version -> crate edition
> > > mapping inside the Rust analyzer script? then we still call the variable
> > > core-edition (which is the crate we need to build).
> >
> > If that's the approach we want to take, that would likely build on
> > https://lore.kernel.org/all/20260109-ra-fix-primitive-v2-1-249852a4145a@gmail.com/.
>
> For fixes, we try to keep them simple as possible in general, i.e.
> like this patch. Or, actually, even simpler: we could keep the
> variable name but use it as the sysroot edition on the other side,
> since it happens to match at the moment.
>
> After all, it is a script call -- the script wants the sysroot
> edition, and we happen to have it from our `core` edition, so it all
> works fine.
>
> i.e. we can just drop the `rust/Makefile` side change for the fix,
> which also means a smaller backport (if we don't use the
> prerrequisite).
This makes sense to me. I can send v2 if there's consensus on this approach.
> Another option is dropping these, if there are no practical
> consequences (did you notice anything very broken using rust-analyzer?
> It would be nice to mention those in the commit message, if you saw
> any), but it seems best to fix it, especially since it comes from the
> sysroot and thus I imagine it could have an impact later on due to
> change in upstream code.
I didn't notice anything specifically broken, but I did confirm that
things break generally if RA is configured with the wrong edition.
This prevents it from indexing sysroot crates (I tested locally with
edition 2015 and observed broken navigation in macros).
In other words it isn't known to be broken today, but a new Rust
release could break it tomorrow.
>
> Cheers,
> Miguel
Powered by blists - more mailing lists