Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve handling of spans around macro result parse errors #81608

Merged
merged 1 commit into from
Feb 2, 2021

Conversation

Aaron1011
Copy link
Member

Fixes #81543

After we expand a macro, we try to parse the resulting tokens as a AST
node. This commit makes several improvements to how we handle spans when
an error occurs:

  • Only ovewrite the original Span if it's a dummy span. This preserves
    a more-specific span if one is available.
  • Use self.prev_token instead of self.token when emitting an error
    message after encountering EOF, since an EOF token always has a dummy
    span
  • Make SourceMap::next_point leave dummy spans unused. A dummy span
    does not have a logical 'next point', since it's a zero-length span.
    Re-using the span span preserves its 'dummy-ness' for other checks

Fixes rust-lang#81543

After we expand a macro, we try to parse the resulting tokens as a AST
node. This commit makes several improvements to how we handle spans when
an error occurs:

* Only ovewrite the original `Span` if it's a dummy span. This preserves
  a more-specific span if one is available.
* Use `self.prev_token` instead of `self.token` when emitting an error
  message after encountering EOF, since an EOF token always has a dummy
  span
* Make `SourceMap::next_point` leave dummy spans unused. A dummy span
  does not have a logical 'next point', since it's a zero-length span.
  Re-using the span span preserves its 'dummy-ness' for other checks
@rust-highfive
Copy link
Collaborator

r? @davidtwco

(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 Jan 31, 2021
@davidtwco
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Feb 1, 2021

📌 Commit 6c14aad has been approved by davidtwco

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 1, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 2, 2021
…as-schievink

Rollup of 11 pull requests

Successful merges:

 - rust-lang#80629 (Add lint for 2229 migrations)
 - rust-lang#81022 (Add Frames Iterator for Backtrace)
 - rust-lang#81481 (move some tests)
 - rust-lang#81485 (Add some tests for associated-type-bounds issues)
 - rust-lang#81492 (rustdoc: Note why `rustdoc::html::markdown` is public)
 - rust-lang#81577 (const_evaluatable: consider sub-expressions to be evaluatable)
 - rust-lang#81599 (Implement `TrustedLen` for `Fuse<I: TrustedLen>`)
 - rust-lang#81608 (Improve handling of spans around macro result parse errors)
 - rust-lang#81609 (Remove the remains of query categories)
 - rust-lang#81630 (Fix overflowing text on mobile when sidebar is displayed)
 - rust-lang#81631 (Remove unneeded `mut` variable)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 255e076 into rust-lang:master Feb 2, 2021
@rustbot rustbot added this to the 1.51.0 milestone Feb 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Too general error for trivial macro when generated function has invalid name
5 participants