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: <CAJ-ks9k_VLyJyxL_pXrq2dW2r+0birOWUmW72Zq9QLXPNjabrg@mail.gmail.com>
Date: Fri, 16 Jan 2026 09:02:46 -0500
From: Tamir Duberstein <tamird@...nel.org>
To: Gary Guo <gary@...yguo.net>
Cc: Jesung Yang <y.j3ms.n@...il.com>, Miguel Ojeda <miguel.ojeda.sandonis@...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 6:53 AM Gary Guo <gary@...yguo.net> wrote:
>
> On Fri Jan 16, 2026 at 4:35 AM GMT, Jesung Yang wrote:
> > On Fri Jan 16, 2026 at 6:22 AM KST, Miguel Ojeda wrote:
> >> 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.
> >
> > Perhaps we should introduce `std-edition` and `proc_macro-edition` in
> > `rust/Makefile`? Passing those down to the script would make things more
> > future-proof.
> >
>
> 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/.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ