Skip to content

Conversation

@nnethercote
Copy link
Contributor

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%.

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%.
@rust-highfive
Copy link
Contributor

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 8, 2019
{ let hi = self.prev_span;
let expr_span = lo.to(hi);
expr_span
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks a bit suspicious.
Have you checked whether this assertion passes on literals passed to macros via literal and expr matchers?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@petrochenkov petrochenkov Feb 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@petrochenkov petrochenkov Feb 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@bors
Copy link
Collaborator

bors commented Feb 12, 2019

☔ The latest upstream changes (presumably #58341) made this pull request unmergeable. Please resolve the merge conflicts.

@Dylan-DPC-zz
Copy link

ping from triage @nnethercote you have a conflict to resolve.

@Dylan-DPC-zz Dylan-DPC-zz added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 4, 2019
@petrochenkov
Copy link
Contributor

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.

@Dylan-DPC-zz
Copy link

thanks @petrochenkov

@nnethercote nnethercote deleted the rm-ast-Lit-span branch April 2, 2020 03:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants