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

[Tamir Duberstein]

On 2026-04-25 12:15:03+00:00, Jesung Yang wrote:
> 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:
> >
> > 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(
> >
> > 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.

Can you explain how function decorators would help? Not entirely clear
to me.

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

Mechanically that would work of course, but it would result in a
flip-flop in the git history. I was hoping to avoid changes at the
caller for this reason.

> 
> > > @@ -335,12 +370,120 @@ def generate_crates(
> >
> > 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

I defer to you on whether or not to do this up front, but I'd like us to
document the procedure either way. If possible, prefer to describe it in
terms of the git CLI rather than GitHub.

> 
> > > [ ... skip 40 lines ... ]
> >
> > 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".

Sorry, it's been a while and now I'm not sure. I likely meant the block
in which the calls to `query_ra_version` and `map_ra_version_baseline`
appear.

> 
> > > [ ... skip 24 lines ... ]
> >
> > either "a different version string" or "different version strings"
> 
> Nice catch, thanks.
> 
> Best regards,
> Jesung