Don't store a Span for ExprKind::Lit in the AST.
#58284
Conversation
Because it's always the same as the `Span` for the surrounding `Expr`. This reduces instruction counts on various benchmarks by up to 0.5%.
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
| { let hi = self.prev_span; | ||
| let expr_span = lo.to(hi); | ||
| expr_span | ||
| }); |
There was a problem hiding this comment.
This looks a bit suspicious.
Have you checked whether this assertion passes on literals passed to macros via literal and expr matchers?
There was a problem hiding this comment.
For
macro m { ... let x = $literal + y; ... }
m!(10);I'd expect the expression span to point to $literal, but the literal span to point to 10.
There was a problem hiding this comment.
For expressions (and other fragments) passed through multiple matchers it would be nice to keep all the "backtrace" of spans by wrapping fragments into "invisible parentheses" on each substitution, but this isn't generally done now.
There was a problem hiding this comment.
I ran the tests and they passed. (In contrast, I tried doing the same no-span-for-literals transformation for HIR and the tests failed; that's how I found out about HIR's lack of parentheses being a problem.)
More compellingly, if you look at the code you can see that I haven't changed behaviour at all: parse_lit uses self.span.to(self.prev_span) for the span, where self.span is obtained at the start of parse_lit and self.prev_span is obtained at the end. And the new code does the same.
There was a problem hiding this comment.
More compellingly, if you look at the code you can see that I haven't changed behaviour at all
OK.
This still goes into the wrong direction IMO, because the spans should ideally be different even if they are not right now.
I'll leave this to eddyb to decide, if AST is going to be radically rewritten for incremental parsing/expansion, then details like this won't matter anyway.
|
☔ The latest upstream changes (presumably #58341) made this pull request unmergeable. Please resolve the merge conflicts. |
|
ping from triage @nnethercote you have a conflict to resolve. |
Dylan-DPC-zz
added
S-waiting-on-author
|
I'd prefer not to do this and eddyb doesn't do reviews right now, so I'm going to close to clean up the queue. |
|
thanks @petrochenkov |
Because it's always the same as the
Spanfor the surroundingExpr.This reduces instruction counts on various benchmarks by up to 0.5%.