Re: [PATCH] scripts: generate_rust_analyzer: compile sysroot with correct edition

["Gary Guo" <gary@garyguo.net>]

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@kernel.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).

Best,
Gary