fix: Implement mixed site hygiene #18264
Conversation
rustbot
added
the
S-waiting-on-review
ChayimFriedman2
force-pushed
the
semi-transparent
branch
from
47ea625 to
1bbce02
Compare
|
☔ The latest upstream changes (presumably #18239) made this pull request unmergeable. Please resolve the merge conflicts. |
ChayimFriedman2
force-pushed
the
semi-transparent
branch
from
1bbce02 to
df94afc
Compare
| @@ -868,7 +920,9 @@ impl ExprCollector<'_> { | |||
| args: Box::new([self.collect_pat_top(e.pat())]), | |||
| ellipsis: None, | |||
| }; | |||
| let label = e.label().map(|label| self.collect_label(label)); | |||
| let label = e.label().map(|label| { | |||
| (self.hygiene_id_for(label.syntax().text_range().start()), self.collect_label(label)) | |||
There was a problem hiding this comment.
(self.hygiene_id_for(label.syntax().text_range().start()), self.collect_label(label))(not relevant to this PR per se) The label.syntax().text_range().start() pattern is being done so often we really need to add a convenience function for fetching the ranges and stuff for typed ast nodes, the syntax() call is just noise
ChayimFriedman2
force-pushed
the
semi-transparent
branch
from
df94afc to
2fe57c1
Compare
Or macro_rules hygiene, or mixed site hygiene. In other words, hygiene for variables and labels but not items. The realization that made me implement this was that while "full" hygiene (aka. def site hygiene) is really hard for us to implement, and will likely involve intrusive changes and performance losses, since every `Name` will have to carry hygiene, mixed site hygiene is very local: it applies only to bodies, and we very well can save it in a side map with minor losses. This fixes one diagnostic in r-a that was about `izip!()` using hygiene (yay!) but it introduces a huge number of others, because of rust-lang#18262. Up until now this issue wasn't a major problem because it only affected few cases, but with hygiene identifiers referred by macros like that are not resolved at all. The next commit will fix that.
ChayimFriedman2
force-pushed
the
semi-transparent
branch
2 times, most recently
from
206b13f to
345d698
Compare
…n macro expansion
E.g.:
```rust
let v;
macro_rules! m { () => { v }; }
```
This was an existing bug, but it was less severe because unless the variable was shadowed it would be correctly resolved. With hygiene however, without this fix the variable is never resolved.
ChayimFriedman2
force-pushed
the
semi-transparent
branch
from
345d698 to
4ac3dc1
Compare
|
@Veykril Addressed comments. About perf impact: This does not have a significant impact on memory (nor do I expect it to have after the removal of the For speed, the integrated benchmarks do not show a meaningful difference, but they are very flaky. If I benchmark the whole thing (including workspace loading) using hyperfine, it is up to 200ms slower, but I tend to think this should be attributed to the workspace loading and not the benchmark itself, if this is even a true regression and not just a measurement error..
|
The realization that made me do this (as explained in detail in the first commit) is that while def-site hygiene is incredibly hard for us, mixed-site hygiene should be easy (well, I underestimated it due to the need of the second commit, but still). And the best part in that is that mixed-site hygiene rules: def-site hygiene is available only on nightly and without a clear path to stabilization, and even when (if) it will stabilize this will still help solving the case of variables/labels.
This brings diagnostics on self down to four (from five, I think? or more) 🎉 and the remaining diagnostics all require next solver (three due to coercion issue, one due to the issue of trait bounds not being preferred).
Best reviewed commit by commit.
Fixes #18262.
Fixes #16342.
Fixes #13758.
Fixes #11681.
Fixes #10535.
(Wow, so many issues! That's heart-filling ❤️)