Properly calculate best failure in macro matching

[Noratrieb]

Previously, we used spans. This was not good. Sometimes, the span of the token that failed to match may come from a position later in the file which has been transcribed into a token stream way earlier in the file. If precisely this token fails to match, we think that it was the best match because its span is so high, even though other arms might have gotten further in the token stream.

We now try to properly use the location in the token stream.

This needs a little cleanup as the best_failure field is getting out of hand but it should be mostly good to go. I hope I didn't violate too many abstraction boundaries..

[rustbot]

r? @davidtwco

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

[Noratrieb]

For reference, this is the current terrible error for the added UI test, which caught my attention as someone was confused and asking about this on the community discord server:

macro_rules! number {
    (neg false, $self:ident) => { $self };
    ($signed:tt => $ty:ty;) => {
        number!(neg $signed, $self);
        //~^ ERROR no rules expected the token `$`
    };
}

number! { false => u8; }

fn main() {}

error: no rules expected the token `false`
 --> src/main.rs:9:11
  |
1 | macro_rules! number {
  | ------------------- when calling this macro
...
9 | number! { false => u8; }
  |           ^^^^^ no rules expected this token in macro call
  |
note: while trying to match `=>`
 --> src/main.rs:3:17
  |
3 |     ($signed:tt => $ty:ty;) => {
  |                 ^^

[Noratrieb]

r? compiler

[compiler-errors]

Thanks, this explanation...

the span of the token that failed to match may come from a position later in the file which has been transcribed into a token stream way earlier in the file

... elucidates the error. Gotta love macro variables.

@bors r+

[bors]

📌 Commit d72a0c4 has been approved by compiler-errors

It is now in the queue for this repository.

[compiler-errors]

The polarity of this fn is a bit confusing -- it reads as it's asking the question "is self better than position", but it's actually "is position better than self"?

[compiler-errors]

kind of a shame that we highlight the whole $self metavariable rather than just the $ token given the primary message of this diagnostic, but w/e