rust-analyzer version: 0.3.2929-standalone (panic message below is from a source build of master with force-always-assert; on the release build the assist silently does nothing and only logs the error)
rustc version: rustc 1.97.0-nightly (ca9a134e0 2026-04-26)
editor or extension: VSCode, rust-analyzer extension 0.3.2929
relevant settings: none
repository link (if public, optional): n/a
code snippet to reproduce:
macro_rules! m { ($e:expr) => { ($e, $e) }; }
struct T(i32);
fn main() {
let u = T(1);
m!(u.0);
}
reproduce:
cursor on T in struct T(i32);
Convert to named struct
expected:
struct T { field1: i32 } with the usage rewritten to m!(u.field1);, or the field reference inside the macro left alone. either way no crash.
actual:
on the release build the assist is offered, applies nothing, and logs the error. on a build with debug assertions the request handler panics:
request handler panicked: some replace change ranges intersect!
left change: ReplaceWithMany(Token(INT_NUMBER@461..462 "0"), [Node(NAME@0..6)]) 0field1
equals
right change: ReplaceWithMany(Token(INT_NUMBER@461..462 "0"), [Node(NAME@0..6)]) 0field1
panicked at crates/syntax/src/syntax_editor/edit_algo.rs:478:5:
some replace change ranges intersect!
cause:
the macro expands $e twice, so the field-reference search returns two FileReferences for the single 0 token in the source. edit_field_references maps both back to the same source token and registers two identical ReplaceWithMany changes, tripping stdx::always!(false, "some replace change ranges intersect!") in edit_algo.rs — the whole edit is discarded.
note:
same root cause as the destructure_tuple_binding / destructure_struct_binding / convert_named_struct_to_tuple_struct issues. related but distinct from #22094 (that one hits the unimplemented! in the dependent-change resolver at edit_algo.rs:298; this one hits the disjointness check at :478).
env:
- rustc: 1.97.0-nightly
- rust-analyzer: 0.3.2929
- OS: Ubuntu
- Editor: VS Code
rust-analyzer version: 0.3.2929-standalone (panic message below is from a source build of master with
force-always-assert; on the release build the assist silently does nothing and only logs the error)rustc version: rustc 1.97.0-nightly (ca9a134e0 2026-04-26)
editor or extension: VSCode, rust-analyzer extension 0.3.2929
relevant settings: none
repository link (if public, optional): n/a
code snippet to reproduce:
reproduce:
cursor on
Tinstruct T(i32);Convert to named struct
expected:
struct T { field1: i32 }with the usage rewritten tom!(u.field1);, or the field reference inside the macro left alone. either way no crash.actual:
on the release build the assist is offered, applies nothing, and logs the error. on a build with debug assertions the request handler panics:
cause:
the macro expands
$etwice, so the field-reference search returns twoFileReferences for the single0token in the source.edit_field_referencesmaps both back to the same source token and registers two identicalReplaceWithManychanges, trippingstdx::always!(false, "some replace change ranges intersect!")inedit_algo.rs— the whole edit is discarded.note:
same root cause as the
destructure_tuple_binding/destructure_struct_binding/convert_named_struct_to_tuple_structissues. related but distinct from #22094 (that one hits theunimplemented!in the dependent-change resolver atedit_algo.rs:298; this one hits the disjointness check at:478).env: