This series adds type annotations to generate_rust_analyzer.py. It is a
subset of an earlier series[0] with formatting-only and drive-by patches
removed (I sent some of these as separate single-patch series).

The final commit leverages type hints to tidy the implementation. It
could be done separately from this series, but serves as a nice
demonstration.

Link: https://lore.kernel.org/all/20250424-rust-analyzer-host-v6-0-40e67fe5c38a@gmail.com/ [0]

Signed-off-by: Tamir Duberstein <tamird@kernel.org>
---
Tamir Duberstein (4):
      scripts: generate_rust_analyzer.py: extract `{build,register}_crate`
      scripts: generate_rust_analyzer.py: drop `"is_proc_macro": false`
      scripts: generate_rust_analyzer.py: add type hints
      scripts: generate_rust_analyzer.py: identify crates explicitly

 scripts/generate_rust_analyzer.py | 256 ++++++++++++++++++++++++++++----------
 1 file changed, 191 insertions(+), 65 deletions(-)
---
base-commit: 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7
change-id: 20260122-rust-analyzer-types-f90bda766749

Best regards,
--  
Tamir Duberstein <tamird@kernel.org>

On Thu, Jan 22, 2026 at 12:30 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> This series adds type annotations to generate_rust_analyzer.py. It is a
> subset of an earlier series[0] with formatting-only and drive-by patches
> removed (I sent some of these as separate single-patch series).
>
> The final commit leverages type hints to tidy the implementation. It
> could be done separately from this series, but serves as a nice
> demonstration.
>
> Link: https://lore.kernel.org/all/20250424-rust-analyzer-host-v6-0-40e67fe5c38a@gmail.com/ [0]
>
> Signed-off-by: Tamir Duberstein <tamird@kernel.org>

Applied to rust-analyzer-next, thanks all!

On Fri, Jan 30, 2026 at 8:57 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> Applied to rust-analyzer-next, thanks all!

To clarify, in most cases, branches are supposed to start from a tag
from Linus, not something in between his tags.

In addition, the idea was that you would start applying patches next
cycle, i.e. normally the branch should start applying patches with an
-rc1 or -rc2 base, rather than at this time of the cycle, and e.g.
finish around -rc5 time, and then you can send me your PR for that
cycle and so on.

Let's talk about it in the next meeting or we can schedule a call.

(The patches seem to be applied with the msgid link and with tags
collected, so that is fine :)

Cheers,
Miguel

On Fri, Jan 30, 2026 at 3:12 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Fri, Jan 30, 2026 at 8:57 PM Tamir Duberstein <tamird@kernel.org> wrote:
> >
> > Applied to rust-analyzer-next, thanks all!
>
> To clarify, in most cases, branches are supposed to start from a tag
> from Linus, not something in between his tags.
>
> In addition, the idea was that you would start applying patches next
> cycle, i.e. normally the branch should start applying patches with an
> -rc1 or -rc2 base, rather than at this time of the cycle, and e.g.
> finish around -rc5 time, and then you can send me your PR for that
> cycle and so on.
>
> Let's talk about it in the next meeting or we can schedule a call.

Sure, will plan on it. I've updated the branch to start with a tag.
Because _this_ series is so invasive, I wanted to get it applied
sooner rather than later to unblock Jesung and Eliot.

>
> (The patches seem to be applied with the msgid link and with tags
> collected, so that is fine :)
>
> Cheers,
> Miguel

On Fri, Jan 30, 2026 at 3:24 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> On Fri, Jan 30, 2026 at 3:12 PM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > On Fri, Jan 30, 2026 at 8:57 PM Tamir Duberstein <tamird@kernel.org> wrote:
> > >
> > > Applied to rust-analyzer-next, thanks all!
> >
> > To clarify, in most cases, branches are supposed to start from a tag
> > from Linus, not something in between his tags.
> >
> > In addition, the idea was that you would start applying patches next
> > cycle, i.e. normally the branch should start applying patches with an
> > -rc1 or -rc2 base, rather than at this time of the cycle, and e.g.
> > finish around -rc5 time, and then you can send me your PR for that
> > cycle and so on.
> >
> > Let's talk about it in the next meeting or we can schedule a call.
>
> Sure, will plan on it. I've updated the branch to start with a tag.
> Because _this_ series is so invasive, I wanted to get it applied
> sooner rather than later to unblock Jesung and Eliot.
>
> >
> > (The patches seem to be applied with the msgid link and with tags
> > collected, so that is fine :)
> >
> > Cheers,
> > Miguel

Apologies for the whiplash, I reset the branch back to rc7. In the
meantime, these commits are available in
https://github.com/tamird/linux/tree/ra-next for folks working on the
next round of improvements.

On Fri, Jan 30, 2026 at 9:32 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> Apologies for the whiplash, I reset the branch back to rc7. In the
> meantime, these commits are available in
> https://github.com/tamird/linux/tree/ra-next for folks working on the
> next round of improvements.

No worries at all, there is no harm done (linux-next was already done
today, and it will likely be closed until Monday).

We can go through the usual timelines and how to prepare a PR etc. in
the call (i.e. the usual bits I explain to new maintainers -- in the
first call we didn't have time for much).

Thanks!

Cheers,
Miguel

On Fri, Jan 30, 2026 at 9:24 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> Sure, will plan on it. I've updated the branch to start with a tag.
> Because _this_ series is so invasive, I wanted to get it applied
> sooner rather than later to unblock Jesung and Eliot.

Thanks (I saw you then reset it to the tag itself, which is what I meant, yeah).

Sometimes maintainers have "private" (as in outside linux-next) for
testing, collaboration, etc., but that can be done outside linux-next.

(We can create such a branch in the same repository if you feel you
need it, e.g. rust-analyzer-dev or -testing or similar.)

Cheers,
Miguel

On Fri Jan 23, 2026 at 2:30 AM KST, Tamir Duberstein wrote:
> This series adds type annotations to generate_rust_analyzer.py. It is a
> subset of an earlier series[0] with formatting-only and drive-by patches
> removed (I sent some of these as separate single-patch series).
>
> The final commit leverages type hints to tidy the implementation. It
> could be done separately from this series, but serves as a nice
> demonstration.
>
> Link: https://lore.kernel.org/all/20250424-rust-analyzer-host-v6-0-40e67fe5c38a@gmail.com/ [0]
>
> Signed-off-by: Tamir Duberstein <tamird@kernel.org>

Great work, thanks! For the entire series,

Reviewed-by: Jesung Yang <y.j3ms.n@gmail.com>
Tested-by: Jesung Yang <y.j3ms.n@gmail.com>

Best regards,
Jesung

> ---
> Tamir Duberstein (4):
>       scripts: generate_rust_analyzer.py: extract `{build,register}_crate`
>       scripts: generate_rust_analyzer.py: drop `"is_proc_macro": false`
>       scripts: generate_rust_analyzer.py: add type hints
>       scripts: generate_rust_analyzer.py: identify crates explicitly
>
>  scripts/generate_rust_analyzer.py | 256 ++++++++++++++++++++++++++++----------
>  1 file changed, 191 insertions(+), 65 deletions(-)
> ---
> base-commit: 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7
> change-id: 20260122-rust-analyzer-types-f90bda766749
>
> Best regards,
> --  
> Tamir Duberstein <tamird@kernel.org>