Rust: Upgrade to rust-analyzer 0.328#21714
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…scripts - Fix Meta usage: Meta is now abstract with subtypes (PathMeta, KeyValueMeta, TokenTreeMeta, etc.) - Fix FormatArgsArg: getName() replaced by getArgName() returning FormatArgsArgName - Add upgrade script (old → new) and downgrade script (new → old) - Update Definitions.qll, PathResolution.qll, BadCtorInitialization.ql, FormatTemplateVariableAccessConstructor.qll Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Re-run cargo fmt after clippy --fix to ensure consistent formatting. Re-run codegen to update generated file tracking for MetaImpl.qll. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Setting proc_macro_processes to 0 causes an index-out-of-bounds panic in ProcMacroServerPool::new when the proc macro server is enabled. Use the same defaults as rust-analyzer itself (1 each). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Remove format_args_arg_names from upgrade delete list (table exists in both schemas with different columns) - Accept updated .expected files for schema changes Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Exclude macro-expanded and attribute paths from PathResolutionConsistency (tokio::main and similar attribute macros resolve to multiple proc macro fns) - Exclude "macro expansion failed" warnings from ExtractionConsistency (compile_error! and undefined macros are expected to fail expansion) - Update pre-existing consistency expectations (net multipleResolvedTargets) - Update type-inference.expected for new RA results Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
c990d17 to
ac27c20
Compare
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
geoffw0
left a comment
There was a problem hiding this comment.
Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300).
Yeah, I feel that, though I suspect some of these files visible in the diff are generated code not marked as such. I've skimmed through all the changes anyway, but I'll have to rely mostly on testing (automated and manual) to build confidence here.
Can I get confirmation:
- that the Copilot-written changes have been reviewed by the author?
- that the upgrade / downgrade scripts have been tested?
| @@ -1,5 +1,5 @@ | |||
| diff --git a/xtask/src/codegen/grammar.rs b/xtask/src/codegen/grammar.rs | |||
There was a problem hiding this comment.
Why do we have a patch / diff committed in the ast generator?
| trait_alias_names.rel: delete | ||
| trait_alias_type_bound_lists.rel: delete | ||
| trait_alias_visibilities.rel: delete | ||
| trait_alias_where_clauses.rel: delete |
There was a problem hiding this comment.
Why do both the upgrade and downgrade scripts just delete a bunch of relations? Don't we have to do anything for the new relations?
| not exists(ew.getLocation()) or ew.getLocation().fromSource() | ||
| (not exists(ew.getLocation()) or ew.getLocation().fromSource()) and | ||
| // macro expansion failures are expected for macros like compile_error! and panic! | ||
| not ew.getMessage().matches("macro expansion failed for%") |
There was a problem hiding this comment.
Won't this logic cover any macro expansion failure warning, whether or not compile_error! or panic! is involved?
| @@ -8,6 +8,9 @@ private import PathResolution | |||
| /** Holds if `p` may resolve to multiple items including `i`. */ | |||
| query predicate multiplePathResolutions(Path p, ItemNode i) { | |||
| p.fromSource() and | |||
| not p.(AstNode).isInMacroExpansion() and | |||
| // exclude paths inside attributes (e.g. `#[tokio::main]`) | |||
| not p.getParentNode*() instanceof Attr and | |||
There was a problem hiding this comment.
Why do we exclude paths inside attributes?
| encoding = "0.2" | ||
| lazy_static = "1.5.0" | ||
| serde_json = "1.0.145" | ||
| serde_json = "1.0.149" |
There was a problem hiding this comment.
Why do we change files in ruby and shared? Do they have to all reference the same versions?
WIP. Let's see what the CI thinks of this. (For the avoidance of doubt, Copilot wrote all of the code, and I'm still working my way through the changes themselves.)