Rust: upgrade to rust-analyzer 0.0.300

[redsun82]

The upgrade script is particularly complex. To test it out, I have:

• compiled the extractor on main
• run the ForTypeRepr, WherePred and TypeBound tests. The only change I observed were locations (for ForBinder instances reconstructed with the upgrade script, the location does not include the for keyword).

[Copilot]

Pull Request Overview

This PR upgrades the rust-analyzer version from 0.0.299 to 0.0.300 as indicated by the title. The upgrade brings updates to the Rust AST schema and affects test expectations across various CodeQL test suites due to improved location precision and renamed AST nodes.

• Updates the Rust AST schema with structural changes including renaming ClosureBinder to ForBinder
• Introduces the ForBinder as a more general construct for closure and type parameter bindings
• Updates dependency versions and test expectations to match the improved rust-analyzer output

Reviewed Changes

Copilot reviewed 204 out of 251 changed files in this pull request and generated no comments.

File	Description
shared/tree-sitter-extractor/Cargo.toml	Updates the rand dependency from version 0.9.1 to 0.9.2
rust/schema/ast.py	Major AST schema changes: renames ClosureBinder to ForBinder, adds Item inheritance to AsmExpr, and updates field references
rust/schema/annotations.py	Updates documentation and annotations to reflect the renaming from ClosureBinder to ForBinder
Multiple .expected files	Updates test expectations to reflect improved location precision from the rust-analyzer upgrade

---

_{You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.}

[aibaars]

This looks like a duplicate database element. Any idea what this is about?

[redsun82]

I think it has to do with how the asm! macro is expanded. Might be good to have a look at the AST

[redsun82]

seems like asm! expands to a MacroBlockExpr that has both its TailExpr and its Statement populated with a copy of the AsmExpr each 😕

[aibaars]

That sounds like a potential bug. The parser is implemented by hand, so it is possible they made a mistake.

[redsun82]

well, it's not the parser populating that, but the asm! special case of macro expansion (so even more ripe for possible errors)

[aibaars]

Or more likely the tail_expr() and statements() methods are wrong. These are typically implemented as "find first child with matching type" and because AsmExpr is now also an Item the statements() method will pick it up too. See also:

https://github.com/rust-lang/rust-analyzer/blob/58bbdec73138b978dd91f1082110168fcdeb4669/crates/syntax/src/ast/generated/nodes.rs#L1561-L1565

https://github.com/rust-lang/rust-analyzer/blob/58bbdec73138b978dd91f1082110168fcdeb4669/crates/syntax/src/ast/generated/nodes.rs#L949-L954

Not sure if you want to file a bug report, a PR to fix it, or whether to patch things up in the extractor or in QL.

Having duplicated nodes is not great, but asm stuff is fairly rare and we don't do much with it so having a bad AST temporarily shouldn't be too much of a problem.

[redsun82]

uh, I think I see what's happening. This is equivalent to that weird situation we have for path segments, where there's a roundabout way of getting the types from it.

When asking for the repeated Stmt children of a MacroBlock, the library just looks at the children for a matching type. Now, because AsmExpr now are also Items, and Items are Stmts, an AsmExpr will match both as the Stmt* children and as the Expr? one. So this stems from a limitation of the ast library in rust-analyzer...

[redsun82]

:jinx-coke:

[redsun82]

can fix that in the extractor

[redsun82]

filed an issue in rust-lang/rust-analyzer#20485

[aibaars]

Looks good to me. Still have some questions though.

[aibaars]

Why do we need to clone now?

[redsun82]

they changed this to return a ref to an Arc, instead of directly a moved Arc like it was before, so we now need to explicitly clone it. It remains an Arc, so cloning is cheap.

[aibaars]

Some of these look like duplicates. Any idea what is going on?

[redsun82]

I'm a bit surprised by the previous results. When I replaced the macro with the expanded code, I could see two distinct ptr results here. So these are legit, they are just squashed together in the macro call location.