Currently you cannot filter out the crate-name argument
RUSTFLAGS_REMOVE_stem.o because the Rust filter-out invocation does not
include that particular argument. Since --crate-name is an argument that
can't be passed multiple times, this means that it's currently not
possible to override the crate name. Thus, remove the --crate-name
argument for drivers. This allows them to override the crate name using
the #![crate_name] annotation.

The --crate-name argument is kept for the crates under rust/ for
simplicity and to avoid changing many of them by adding #![crate_name].

The rust analyzer script is updated to use rustc to obtain the crate
name of the driver crates, which picks up the right name when it is
configured via #![crate_name] or not.

Note that the crate name in the python script is not actually that
important - the only place where the name actually affects anything is
in the 'deps' array which specifies an index and name for each
dependency, and determines what that dependency is called in *this*
crate. (The same crate may be called different things in each
dependency.) Since driver crates are leaf crates, this doesn't apply and
the rustc invocation only affects the 'display_name' parameter.

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 scripts/Makefile.build            | 1 -
 scripts/generate_rust_analyzer.py | 8 +++++++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 32e209bc7985..adc3e2d1ac78 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -332,7 +332,6 @@ rust_common_cmd = \
 	-Zcrate-attr='feature($(rust_allowed_features))' \
 	-Zunstable-options --extern pin_init --extern kernel \
 	--crate-type rlib -L $(objtree)/rust/ \
-	--crate-name $(basename $(notdir $@)) \
 	--sysroot=/dev/null \
 	--out-dir $(dir $@) --emit=dep-info=$(depfile)
 
diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
index f9b545104f21..d25bc3d7e719 100755
--- a/scripts/generate_rust_analyzer.py
+++ b/scripts/generate_rust_analyzer.py
@@ -194,6 +194,12 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
         except FileNotFoundError:
             return False
 
+    def get_crate_name(path):
+        return subprocess.check_output(
+            [os.environ["RUSTC"], "--print", "crate-name", path],
+            stdin=subprocess.DEVNULL,
+        ).decode('utf-8').strip()
+
     # Then, the rest outside of `rust/`.
     #
     # We explicitly mention the top-level folders we want to cover.
@@ -212,7 +218,7 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
 
             logging.info("Adding %s", name)
             append_crate(
-                name,
+                get_crate_name(path),
                 path,
                 ["core", "kernel", "pin_init"],
                 cfg=cfg,

-- 
2.53.0.473.g4a7958ca14-goog

On Tue Mar 10, 2026 at 2:53 PM GMT, Alice Ryhl wrote:
> Currently you cannot filter out the crate-name argument
> RUSTFLAGS_REMOVE_stem.o because the Rust filter-out invocation does not
> include that particular argument. Since --crate-name is an argument that
> can't be passed multiple times, this means that it's currently not
> possible to override the crate name. Thus, remove the --crate-name
> argument for drivers. This allows them to override the crate name using
> the #![crate_name] annotation.

Could you add a line about the fact that crate name have no impact on output
locations as we always use fixed emit paths, as we discussed in v1?

With that change:

Acked-by: Gary Guo <gary@garyguo.net>

>
> The --crate-name argument is kept for the crates under rust/ for
> simplicity and to avoid changing many of them by adding #![crate_name].
>
> The rust analyzer script is updated to use rustc to obtain the crate
> name of the driver crates, which picks up the right name when it is
> configured via #![crate_name] or not.
>
> Note that the crate name in the python script is not actually that
> important - the only place where the name actually affects anything is
> in the 'deps' array which specifies an index and name for each
> dependency, and determines what that dependency is called in *this*
> crate. (The same crate may be called different things in each
> dependency.) Since driver crates are leaf crates, this doesn't apply and
> the rustc invocation only affects the 'display_name' parameter.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
>  scripts/Makefile.build            | 1 -
>  scripts/generate_rust_analyzer.py | 8 +++++++-
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 32e209bc7985..adc3e2d1ac78 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -332,7 +332,6 @@ rust_common_cmd = \
>  	-Zcrate-attr='feature($(rust_allowed_features))' \
>  	-Zunstable-options --extern pin_init --extern kernel \
>  	--crate-type rlib -L $(objtree)/rust/ \
> -	--crate-name $(basename $(notdir $@)) \
>  	--sysroot=/dev/null \
>  	--out-dir $(dir $@) --emit=dep-info=$(depfile)
>  
> diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
> index f9b545104f21..d25bc3d7e719 100755
> --- a/scripts/generate_rust_analyzer.py
> +++ b/scripts/generate_rust_analyzer.py
> @@ -194,6 +194,12 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
>          except FileNotFoundError:
>              return False
>  
> +    def get_crate_name(path):
> +        return subprocess.check_output(
> +            [os.environ["RUSTC"], "--print", "crate-name", path],
> +            stdin=subprocess.DEVNULL,
> +        ).decode('utf-8').strip()
> +
>      # Then, the rest outside of `rust/`.
>      #
>      # We explicitly mention the top-level folders we want to cover.
> @@ -212,7 +218,7 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
>  
>              logging.info("Adding %s", name)
>              append_crate(
> -                name,
> +                get_crate_name(path),
>                  path,
>                  ["core", "kernel", "pin_init"],
>                  cfg=cfg,

On Tue, Mar 10, 2026 at 02:53:40PM +0000, Alice Ryhl wrote:
> Currently you cannot filter out the crate-name argument
> RUSTFLAGS_REMOVE_stem.o because the Rust filter-out invocation does not
> include that particular argument. Since --crate-name is an argument that
> can't be passed multiple times, this means that it's currently not
> possible to override the crate name. Thus, remove the --crate-name
> argument for drivers. This allows them to override the crate name using
> the #![crate_name] annotation.
> 
> The --crate-name argument is kept for the crates under rust/ for
> simplicity and to avoid changing many of them by adding #![crate_name].
> 
> The rust analyzer script is updated to use rustc to obtain the crate
> name of the driver crates, which picks up the right name when it is
> configured via #![crate_name] or not.
> 
> Note that the crate name in the python script is not actually that
> important - the only place where the name actually affects anything is
> in the 'deps' array which specifies an index and name for each
> dependency, and determines what that dependency is called in *this*
> crate. (The same crate may be called different things in each
> dependency.) Since driver crates are leaf crates, this doesn't apply and
> the rustc invocation only affects the 'display_name' parameter.
> 
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
>  scripts/Makefile.build            | 1 -
>  scripts/generate_rust_analyzer.py | 8 +++++++-
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 32e209bc7985..adc3e2d1ac78 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -332,7 +332,6 @@ rust_common_cmd = \
>  	-Zcrate-attr='feature($(rust_allowed_features))' \
>  	-Zunstable-options --extern pin_init --extern kernel \
>  	--crate-type rlib -L $(objtree)/rust/ \
> -	--crate-name $(basename $(notdir $@)) \
>  	--sysroot=/dev/null \
>  	--out-dir $(dir $@) --emit=dep-info=$(depfile)
>  
> diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
> index f9b545104f21..d25bc3d7e719 100755
> --- a/scripts/generate_rust_analyzer.py
> +++ b/scripts/generate_rust_analyzer.py
> @@ -194,6 +194,12 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
>          except FileNotFoundError:
>              return False
>  
> +    def get_crate_name(path):
> +        return subprocess.check_output(
> +            [os.environ["RUSTC"], "--print", "crate-name", path],
> +            stdin=subprocess.DEVNULL,
> +        ).decode('utf-8').strip()
> +
>      # Then, the rest outside of `rust/`.
>      #
>      # We explicitly mention the top-level folders we want to cover.
> @@ -212,7 +218,7 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
>  
>              logging.info("Adding %s", name)

Actually I guess we might want get_crate_name(path) here (or just path).
But the other uses of 'name' should stay as-is.

>              append_crate(
> -                name,
> +                get_crate_name(path),
>                  path,
>                  ["core", "kernel", "pin_init"],
>                  cfg=cfg,
> 
> -- 
> 2.53.0.473.g4a7958ca14-goog
>

On 2026-03-10 15:05:48+00:00, Alice Ryhl wrote:
> On Tue, Mar 10, 2026 at 02:53:40PM +0000, Alice Ryhl wrote:
> 
> > Currently you cannot filter out the crate-name argument
> > RUSTFLAGS_REMOVE_stem.o because the Rust filter-out invocation does not
> > include that particular argument. Since --crate-name is an argument that
> > can't be passed multiple times, this means that it's currently not
> > possible to override the crate name. Thus, remove the --crate-name
> > argument for drivers. This allows them to override the crate name using
> > the #![crate_name] annotation.
> > 
> > The --crate-name argument is kept for the crates under rust/ for
> > simplicity and to avoid changing many of them by adding #![crate_name].
> > 
> > The rust analyzer script is updated to use rustc to obtain the crate
> > name of the driver crates, which picks up the right name when it is
> > configured via #![crate_name] or not.
> > 
> > Note that the crate name in the python script is not actually that
> > important - the only place where the name actually affects anything is
> > in the 'deps' array which specifies an index and name for each
> > dependency, and determines what that dependency is called in *this*
> > crate. (The same crate may be called different things in each
> > dependency.) Since driver crates are leaf crates, this doesn't apply and
> > the rustc invocation only affects the 'display_name' parameter.
> > 
> > Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> > ---
> >  scripts/Makefile.build            | 1 -
> >  scripts/generate_rust_analyzer.py | 8 +++++++-
> >  2 files changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > index 32e209bc7985..adc3e2d1ac78 100644
> > --- a/scripts/Makefile.build
> > +++ b/scripts/Makefile.build
> > @@ -332,7 +332,6 @@ rust_common_cmd = \
> >  	-Zcrate-attr='feature($(rust_allowed_features))' \
> >  	-Zunstable-options --extern pin_init --extern kernel \
> >  	--crate-type rlib -L $(objtree)/rust/ \
> > -	--crate-name $(basename $(notdir $@)) \
> >  	--sysroot=/dev/null \
> >  	--out-dir $(dir $@) --emit=dep-info=$(depfile)
> >  
> > diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
> > index f9b545104f21..d25bc3d7e719 100755
> > --- a/scripts/generate_rust_analyzer.py
> > +++ b/scripts/generate_rust_analyzer.py

Did you want me to take this part through rust-analyzer-next? There's a
significant rewrite there that adds type annotations to this file, so it
would be better if this patch could apply on top (with annotations).

> > @@ -194,6 +194,12 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
> >          except FileNotFoundError:
> >              return False
> >  
> > +    def get_crate_name(path):
> > +        return subprocess.check_output(
> > +            [os.environ["RUSTC"], "--print", "crate-name", path],
> > +            stdin=subprocess.DEVNULL,
> > +        ).decode('utf-8').strip()

It would be good to extract shelling out to rustc into a helper, now
that we have two instances of this pattern.

> > +
> >      # Then, the rest outside of `rust/`.
> >      #
> >      # We explicitly mention the top-level folders we want to cover.
> > @@ -212,7 +218,7 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
> >  
> >              logging.info("Adding %s", name)
> 
> Actually I guess we might want get_crate_name(path) here (or just path).
> But the other uses of 'name' should stay as-is.

It would probably be good to rename `name` to reduce some of this
confusion.

On Tue, Mar 10, 2026 at 4:45 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> Did you want me to take this part through rust-analyzer-next? There's a
> significant rewrite there that adds type annotations to this file, so it
> would be better if this patch could apply on top (with annotations).

We should ideally avoid breaking it between commits, so we could apply
it after I merge your future PR, with your Acked-by. Another way is
next cycle, through rust-analyzer-next.

Cheers,
Miguel

On Tue, Mar 10, 2026 at 3:13 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Tue, Mar 10, 2026 at 4:45 PM Tamir Duberstein <tamird@kernel.org> wrote:
> >
> > Did you want me to take this part through rust-analyzer-next? There's a
> > significant rewrite there that adds type annotations to this file, so it
> > would be better if this patch could apply on top (with annotations).
>
> We should ideally avoid breaking it between commits, so we could apply
> it after I merge your future PR, with your Acked-by. Another way is
> next cycle, through rust-analyzer-next.

The change to `generate_rust_analyzer.py` is safe to land even without
the other changes in this series, so it should be possible to take
that through rust-analyzer-next this cycle and then take the other
changes in this series after my PR. Do I understand correctly?

On Tue, Mar 10, 2026 at 03:38:58PM -0400, Tamir Duberstein wrote:
> On Tue, Mar 10, 2026 at 3:13 PM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > On Tue, Mar 10, 2026 at 4:45 PM Tamir Duberstein <tamird@kernel.org> wrote:
> > >
> > > Did you want me to take this part through rust-analyzer-next? There's a
> > > significant rewrite there that adds type annotations to this file, so it
> > > would be better if this patch could apply on top (with annotations).

I will rebase on rust-analyzer-next and resend once discussion has died
down.

> > We should ideally avoid breaking it between commits, so we could apply
> > it after I merge your future PR, with your Acked-by. Another way is
> > next cycle, through rust-analyzer-next.
> 
> The change to `generate_rust_analyzer.py` is safe to land even without
> the other changes in this series, so it should be possible to take
> that through rust-analyzer-next this cycle and then take the other
> changes in this series after my PR. Do I understand correctly?

I have no strong opinion on this. I can split it if you want me to, but
I'm also fine with Miguel landing the entire thing in rust-next, or with
Tamir landing the entire thing in rust-analyzer-next. Just let me know
what you want me to do.

Alice

On Tue, Mar 10, 2026 at 8:39 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> The change to `generate_rust_analyzer.py` is safe to land even without
> the other changes in this series, so it should be possible to take
> that through rust-analyzer-next this cycle and then take the other
> changes in this series after my PR. Do I understand correctly?

Yeah, I think we could do that, but that means justifying the
rust-analyzer change on its own, which currently wouldn't be needed.

Sometimes we do things "for the future" to simplify landing them, but
do we need that here?

Either way, what I would suggest is that the changes take into account
your changes, i.e. to base the patch on top of what you have in the
branch, so that we can review it and so that you are happy with it one
way or the other.

Cheers,
Miguel

On Tue, Mar 10, 2026 at 8:58 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> and so that you are happy with it one
> way or the other.

By this I mean that either way I would wait for you to be OK with the
change (e.g. with an Acked-by if we put it after merging your branch).

Cheers,
Miguel

On Tue, Mar 10, 2026 at 4:01 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Tue, Mar 10, 2026 at 8:58 PM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > and so that you are happy with it one
> > way or the other.
>
> By this I mean that either way I would wait for you to be OK with the
> change (e.g. with an Acked-by if we put it after merging your branch).

Makes sense to me (that this goes through rust-next after my PR).

Thanks!