Skip to content

Spans for Paths can be incorrect #39450

Closed

Description

@nrc

Consider the following example (from term-painter):

macro_rules! impl_format {
    ($symbol:expr, $fmt:ident) => {
        impl<T: fmt::$fmt> fmt::$fmt for Painted<T> {
            fn fmt(&self, f: &mut fmt::Formatter) -> Result<(), fmt::Error> {
                panic!()
            }
        }
    }
}

impl_format!("{}", Display);

On the third line are two paths of the form fmt::$fmt, after expansion, these are both fmt::Display. The way spans for paths are calculated we take the start of fmt and the end of Display (see parse_path in parser.rs), this means the span for the path is 9 lines long and pretty incoherent. Annoyingly, this span does not get an expansion id, and thus has no indication that it came from generated code. This is visible in error messages:

   |
9  |           impl<T: fmt::$fmt> fmt::$fmt for Painted<T> {
   |  _________________^ starting here...
10 | |             fn fmt(&self, f: &mut fmt::Formatter) -> Result<(), fmt::Error> {
11 | |                 panic!()
12 | |             }
13 | |         }
14 | |     }
15 | | }
16 | |
17 | | impl_format!("{}", Display);
   | | -------------------------^--
   | |_|________________________|
   |   |                        ...ending here
   |   in this macro invocation

Activity

  1. added
    A-diagnosticsArea: Messages for errors, warnings, and lints
    on Feb 1, 2017
  2. oli-obk commented on Feb 2, 2017

    @oli-obk
    Contributor

    We've had the same issue in clippy: https://github.com/Manishearth/rust-clippy/issues/1404#issuecomment-275861252

    copying over the comment:

    rustc expands issue_1404!(0) to macro_tokens 0 macro_tokens. When these tokens are parsed, the parser stores a tokens position, parses on, and creates a span from the stored position to where it is now. But when you parse 0 inside those macro_tokens, you get a span from inside the macro_rules to behind 0, which makes no sense.

  3. self-assigned this
    on Feb 4, 2017
  4. jseyfried commented on Feb 8, 2017

    @jseyfried
    Contributor
  5. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Mar 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-diagnosticsArea: Messages for errors, warnings, and lintsT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions