From: Tamir Duberstein <tamird@gmail.com>

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.

Note that backporting this will conflict unless commit 46e58a9637ec ("rust:
kbuild: introduce `core-flags` and `core-skip_flags`") is also backported.

Fixes: f4daa80d6be7 ("rust: compile libcore with edition 2024 for 1.87+")
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
---
 rust/Makefile                     |  7 ++++---
 scripts/generate_rust_analyzer.py | 11 +++++------
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/rust/Makefile b/rust/Makefile
index 4dcc2eff51cb..a8ded6c07255 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -67,7 +67,7 @@ cfgs-to-flags = $(patsubst %,--cfg='%',$1)
 core-cfgs := \
     no_fp_fmt_parse
 
-core-edition := $(if $(call rustc-min-version,108700),2024,2021)
+sysroot_edition := $(if $(call rustc-min-version,108700),2024,2021)
 
 core-skip_flags := \
     --edition=2021 \
@@ -75,7 +75,7 @@ core-skip_flags := \
     -Wrustdoc::unescaped_backticks
 
 core-flags := \
-    --edition=$(core-edition) \
+    --edition=$(sysroot_edition) \
     $(call cfgs-to-flags,$(core-cfgs))
 
 proc_macro2-cfgs := \
@@ -567,7 +567,8 @@ quiet_cmd_rustc_library = $(if $(skip_clippy),RUSTC,$(RUSTC_OR_CLIPPY_QUIET)) L
 
 rust-analyzer:
 	$(Q)MAKEFLAGS= $(srctree)/scripts/generate_rust_analyzer.py \
-		--cfgs='core=$(core-cfgs)' $(core-edition) \
+		$(sysroot_edition) \
+		--cfgs='core=$(core-cfgs)' \
 		--cfgs='proc_macro2=$(proc_macro2-cfgs)' \
 		--cfgs='quote=$(quote-cfgs)' \
 		--cfgs='syn=$(syn-cfgs)' \
diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
index 6061bd6e2ebd..47e49f8dacbc 100755
--- a/scripts/generate_rust_analyzer.py
+++ b/scripts/generate_rust_analyzer.py
@@ -19,7 +19,7 @@ def args_crates_cfgs(cfgs):
 
     return crates_cfgs
 
-def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edition):
+def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, sysroot_edition):
     # Generate the configuration list.
     cfg = []
     with open(objtree / "include" / "generated" / "rustc_cfg") as fd:
@@ -61,7 +61,6 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
         display_name,
         deps,
         cfg=[],
-        edition="2021",
     ):
         append_crate(
             display_name,
@@ -69,13 +68,13 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
             deps,
             cfg,
             is_workspace_member=False,
-            edition=edition,
+            edition=sysroot_edition,
         )
 
     # NB: sysroot crates reexport items from one another so setting up our transitive dependencies
     # here is important for ensuring that rust-analyzer can resolve symbols. The sources of truth
     # for this dependency graph are `(sysroot_src / crate / "Cargo.toml" for crate in crates)`.
-    append_sysroot_crate("core", [], cfg=crates_cfgs.get("core", []), edition=core_edition)
+    append_sysroot_crate("core", [], cfg=crates_cfgs.get("core", []))
     append_sysroot_crate("alloc", ["core"])
     append_sysroot_crate("std", ["alloc", "core"])
     append_sysroot_crate("proc_macro", ["core", "std"])
@@ -200,7 +199,7 @@ def main():
     parser = argparse.ArgumentParser()
     parser.add_argument('--verbose', '-v', action='store_true')
     parser.add_argument('--cfgs', action='append', default=[])
-    parser.add_argument("core_edition")
+    parser.add_argument("sysroot_edition")
     parser.add_argument("srctree", type=pathlib.Path)
     parser.add_argument("objtree", type=pathlib.Path)
     parser.add_argument("sysroot", type=pathlib.Path)
@@ -217,7 +216,7 @@ def main():
     assert args.sysroot in args.sysroot_src.parents
 
     rust_project = {
-        "crates": generate_crates(args.srctree, args.objtree, args.sysroot_src, args.exttree, args.cfgs, args.core_edition),
+        "crates": generate_crates(args.srctree, args.objtree, args.sysroot_src, args.exttree, args.cfgs, args.sysroot_edition),
         "sysroot": str(args.sysroot),
     }
 

---
base-commit: 74e15ac34b098934895fd27655d098971d2b43d9
change-id: 20260115-rust-analyzer-sysroot-5fb95aa985d2

Best regards,
--  
Tamir Duberstein <tamird@gmail.com>

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.

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@gmail.com>

Cc'ing Jesung who is becoming a reviewer for rust-analyzer.

Thanks!

Cheers,
Miguel

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.

Best regards,
Jesung

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

On Fri, Jan 16, 2026 at 6:53 AM Gary Guo <gary@garyguo.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@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).

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/.

On Fri, Jan 16, 2026 at 3:03 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> On Fri, Jan 16, 2026 at 6:53 AM Gary Guo <gary@garyguo.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).

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.

Cheers,
Miguel

On Fri, Jan 16, 2026 at 9:43 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Fri, Jan 16, 2026 at 3:03 PM Tamir Duberstein <tamird@kernel.org> wrote:
> >
> > On Fri, Jan 16, 2026 at 6:53 AM Gary Guo <gary@garyguo.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

On Fri, Jan 16, 2026 at 4:39 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> This makes sense to me. I can send v2 if there's consensus on this approach.

Sounds good, thanks!

I guess I could also do it on apply since, unless I missed something,
it just requires dropping all the `rust/Makefile` changes, but a v2 is
always good for clarity.

> 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.

Yeah, agreed.

Cheers,
Miguel

On Thu, Jan 15, 2026 at 4:23 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> 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")

Good point, I hadn't considered that (nor did I do that archaeology).

> 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.

Ah, I think I wrote that when I was under the impression that
`--sysroot-edition` was a named argument to the script but it turned
out to be positional. So: you are right that the message should be
updated.

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

Ah, thanks. If the prerequisite isn't backported, who provides the
resolved patch?

>
> > 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.

Ack, I guess that will have to happen at apply time for this one?

> > Signed-off-by: Tamir Duberstein <tamird@gmail.com>
>
> Cc'ing Jesung who is becoming a reviewer for rust-analyzer.
>
> Thanks!
>
> Cheers,
> Miguel

Thanks Miguel.

On Thu, Jan 15, 2026 at 10:36 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> Ah, thanks. If the prerequisite isn't backported, who provides the
> resolved patch?

The maintainers, typically, or perhaps authors of the patch -- when a
patch doesn't apply cleanly, the stable team sends an email to the
relevant people with instructions on the top, which then can used to
provide them with a resolution (essentially replying with a new
patch).

> Ack, I guess that will have to happen at apply time for this one?

Yeah, I can do that:

Cc: stable@vger.kernel.org

> Thanks Miguel.

You're welcome!

Cheers,
Miguel