refactor: reorganize_definitions: fix multi-namespace imports splitting - #1925
Conversation
e47e2b3 to
072a330
Compare
072a330 to
bed6930
Compare
bed6930 to
1398d79
Compare
1398d79 to
2343a08
Compare
2343a08 to
657815f
Compare
657815f to
a33e792
Compare
a33e792 to
f9b5346
Compare
d908672 to
f058f77
Compare
04579b8 to
011e000
Compare
011e000 to
1902a83
Compare
1902a83 to
634aac3
Compare
634aac3 to
7e7321b
Compare
7e7321b to
2f498ad
Compare
2f498ad to
6b3491e
Compare
6b3491e to
29ba8db
Compare
29ba8db to
5748cf2
Compare
81850d6 to
bc8c764
Compare
22fd4d9 to
c486129
Compare
c486129 to
3331801
Compare
thedataking
left a comment
There was a problem hiding this comment.
Review of stack 1953: the newly generated split import needs to preserve the original binding name.
| self.path_mapping.get(&def_id) | ||
| { | ||
| if other_mod_id != *parent { | ||
| if !path.ast_equiv(&retained_path) { |
There was a problem hiding this comment.
[P2] Preserve aliases when emitting the second namespace import
This broader split condition now reaches use_simple_item(path, None::<String>) when the two targets are in the same module but have different names. That generated import ignores the original as alias and can introduce a name collision.
I reproduced this at stack head using reorganize_split_renamed_import.rs: change the import in user to use crate::dest::dest_h::tick as alias;, change its type/value uses to alias, and add fn tick() {} to user. The input compiles. The output adds use crate::dest::tick; alongside that function, producing E0255 (tick defined multiple times). The earlier transform produces compiling output for this case.
The synthesized import should preserve the original binding name, so this case emits use crate::dest::tick as alias;.
3331801 to
dc52d84
Compare
Regression test: `test_reorganize_split_renamed_import` (`tests/snapshots/reorganize_split_renamed_import.rs`). The original two-external-crates scenario cannot be built in the single-file snapshot harness, so the test exercises the equivalent local case the old parent-id comparison also got wrong: a collision-renamed type target (`tick_1`) and a value target (`tick`) in the *same* destination module. Pre-fix output omits the value-namespace `use crate::dest::tick;`.
The split loop now reconstructs the path the retained import was rewritten to
and compares target paths with `ast_equiv` instead of comparing parent module
NodeIds, so external targets (all `DUMMY_NODE_ID`) are handled correctly.
Regression test: `test_reorganize_split_renamed_import`
(`tests/snapshots/reorganize_split_renamed_import.rs`). The original
two-external-crates scenario cannot be built in the single-file snapshot
harness, so the test exercises the equivalent local case the old parent-id
comparison also got wrong: a collision-renamed type target (`tick_1`) and a
value target (`tick`) in the *same* destination module. Pre-fix output omits
the value-namespace `use crate::dest::tick;`.
Follow-on bug found while writing the test: the split-import insertion had
never actually fired in any test before, and when the synthesized `use` is
inserted next to the rewritten retained import *with a comment attached
directly above it*, the rewriter panics with "conflicting rewrites" — the
sequence splice absorbs the comment into its span and overlaps the item's own
path rewrite. The test sidesteps it by keeping comments away from the import;
the rewriter/seq-edit interplay still needs a real fix.
`:1144-1172`. `match_exports` stores `parent: DUMMY_NODE_ID` for all external
replacements (`:673`), and `other_mod_id` falls back to `DUMMY_NODE_ID`
(`:1153`). So when a single `use` resolves in two namespaces to targets in two
*different* external crates/modules, `other_mod_id != *parent` compares
`DUMMY == DUMMY`, concludes "same module", and skips emitting the second
import — the retained import is rewritten to the first namespace's path and
the other binding is lost.
The redundancy check further down explicitly documents this exact pitfall
("DUMMY_NODE_ID represents every external module and cannot prove path
equality", `:1286-1295`) but this earlier check doesn't apply the same rule.
dc52d84 to
288f714
Compare
Stack created with GitHub Stacks CLI • Give Feedback 💬