Spans for Paths can be incorrect

[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

[oli-obk]

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.

[jseyfried]

cc #23480