Re: [PATCH v4 1/2] scripts: generate_rust_analyzer.py: add versioning infrastructure

[Jesung Yang]

On Thu, Mar 19, 2026 at 3:02 PM Tamir Duberstein <tamird@xxxxxxxxxx> wrote:
>
> On Tue, 17 Mar 2026 18:29:54 +0900, Jesung Yang <y.j3ms.n@xxxxxxxxx> wrote:
> > diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
> > index b4a55344688d..21832763c5be 100755
> > --- a/scripts/generate_rust_analyzer.py
> > +++ b/scripts/generate_rust_analyzer.py
> > @@ -49,7 +54,19 @@ class CrateWithGenerated(Crate):
> >      source: Source
> >
> >
> > +class RustProject(TypedDict):
> > +    crates: List[Crate]
> > +    sysroot: str
> > +
>
> Could we move this type down so it's closer to its site of use? It's ~350 linues down.

Sure, will do.

> > @@ -200,67 +227,70 @@ def generate_crates(
> >              edition=core_edition,
> >          )
> >
> > +    def sysroot_deps(*deps: Optional[Dependency]) -> List[Dependency]:
> > +        return [dep for dep in deps if dep is not None]
> > +
> >      # NB: sysroot crates reexport items from one another so setting up our transitive dependencies
>
> It would be great to avoid having to sprinkle this everywhere, though I admit
> it's not immediately obvious to me how to achieve it. Maybe we can live with it
> until the MSRV bump. Again, would be great to structure this in a way that
> makes that cleanup simple when the time comes.

I considered using function decorators, but on second thought, that
would just be another way of sprinkling functions around.

In my view, the cleanup should still be fairly straightforward even with
the current `sysroot_deps` approach. We could just remove the function
and let mypy (or an LSP) flag the undefined function error/warnings.
Does that sound reasonable to you?

> > @@ -335,12 +370,120 @@ def generate_crates(
> > [ ... skip 17 lines ... ]
> > +    Represents rust-analyzer compatibility baselines. Concrete versions are mapped to the most
> > +    recent baseline they have reached. Must be in release order.
> > +    """
> > +
> > +    # v0.3.1877, released on 2024-03-11; shipped with the rustup 1.78 toolchain.
> > +    DEFAULT = (
>
> There should be a note here explaining that this should be bumped when MSRV is
> bumped, and how to obtain the new values that should go here. It's really
> important that the string MSRV appears as it's a likely grep target for when
> that pointer is updated.

I'll add a comment about the MSRV bump. Unfortunately, there isn't a
reliable way to programmatically retrieve the matching rust-analyzer
release AFAICT. I typically follow these steps:

1. Look for the commit history of `src/tools/rust-analyzer` in the
   upstream Rust repository (either locally or via GitHub [1]).
2. Check the latest merge commit from on the rust-analyzer side, which
   usually starts with "Merge pull request #<PR_ID>".
3. Search for that <PR_ID> on the rust-analyzer release page [2].
4. Grab the version string and release date.

Perhaps the better approach is to perform these manual checks upfront
for versions 1.86 through 1.94, at which point this version
infrastructure can finally be removed.

[1] https://github.com/rust-lang/rust/commits/<TAG>/src/tools/rust-analyzer
[2] https://github.com/rust-lang/rust-analyzer/releases

> > [ ... skip 40 lines ... ]
> > +            ),
> > +            "sysroot": str(sysroot),
> > +        }
> > +    else:
> > +        assert_never(version_info)
> > +
>
> The call to generate_crates should probably be below the block that synthesizes RaVersionInfo.

Sorry, could you elaborate on this? Not sure what you meant by
"synthesizes RaVersionInfo".

> > [ ... skip 24 lines ... ]
> > +        # `rust-analyzer --version` shows different version string depending on how the binary
> > +        # is built: it may print either the Rust version or the rust-analyzer version itself.
> > +        # To distinguish between them, we leverage rust-analyzer's versioning convention.
> > +        #
> > +        # See:
> > +        # - https://github.com/rust-lang/rust-analyzer/blob/fad5c3d2d642/xtask/src/dist.rs#L19-L21
>
> either "a different version string" or "different version strings"

Nice catch, thanks.

Best regards,
Jesung