[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72kd9bHdKaAm=8xCUhSHMy2csyVed69bOc4dXyFAW4sfuw@mail.gmail.com>
Date: Thu, 15 Jan 2026 22:22:59 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Tamir Duberstein <tamird@...nel.org>, Jesung Yang <y.j3ms.n@...il.com>
Cc: 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>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org, Tamir Duberstein <tamird@...il.com>
Subject: Re: [PATCH] scripts: generate_rust_analyzer: compile sysroot with
correct edition
On Thu, Jan 15, 2026 at 5:35 PM Tamir Duberstein <tamird@...nel.org> wrote:
>
> Rename `core-edition` to `sysroot-edition` to align with the naming used
> to refer to standard library crates in `generate_rust_analyzer.py` and
> apply it to all standard library crates rather than just core.
I think, in principle, even the sysroot crates may have different
editions, which I think I used that variable name.
For instance, in the move to 2024, it seems all happened at once in
1.87.0 in these upstream commits, so that seems OK:
0e071c2c6a58 ("Migrate core to Rust 2024")
f505d4e8e380 ("Migrate alloc to Rust 2024")
0b2489c226c3 ("Migrate proc_macro to Rust 2024")
993359e70112 ("Migrate std to Rust 2024")
But in the previous move to 2021, `std` moved in 1.59.0, while the
others in 1.60.0:
b656384d8398 ("Update stdlib to the 2021 edition")
06a1c14d52a8 ("Switch all libraries to the 2021 edition")
Hmm... I guess the new name is fine, but we may need to go back to
separate naming eventually if they get updated at different times next
time.
By the way, it says `sysroot-edition` in the message -- I guess you
then later used underscore because it is now not attached to a
particular crate? In that case, I can update the message.
> Note that backporting this will conflict unless commit 46e58a9637ec ("rust:
> kbuild: introduce `core-flags` and `core-skip_flags`") is also backported.
This normally is solved on backporting time providing a resolved patch
or, if you think it is worth backporting the other one too, as a
prerequisite in the Cc: stable lines (see
Documentation/process/stable-kernel-rules.rst).
> Fixes: f4daa80d6be7 ("rust: compile libcore with edition 2024 for 1.87+")
Since this commit is previous to existing kernel branches and you
mention it above, please consider adding Cc: stable.
> Signed-off-by: Tamir Duberstein <tamird@...il.com>
Cc'ing Jesung who is becoming a reviewer for rust-analyzer.
Thanks!
Cheers,
Miguel
Powered by blists - more mailing lists