Coalesce unreachable_patterns lint messages

[mejrs]

Rather than emit a message for every unreachable pattern in a match, this PR coalesces them to one message. This is part of an effort to make mistakes like #68433 less spammy.

For example, it combines all of these...

error: unreachable pattern
  --> $DIR/exhaustiveness-unreachable-pattern.rs:23:9
   |
LL |         (1, 3) => {}
   |         ^^^^^^

error: unreachable pattern
  --> $DIR/exhaustiveness-unreachable-pattern.rs:24:9
   |
LL |         (1, 4) => {}
   |         ^^^^^^

error: unreachable pattern
  --> $DIR/exhaustiveness-unreachable-pattern.rs:25:9
   |
LL |         (2, 4) => {}
   |         ^^^^^^

error: unreachable pattern
  --> $DIR/exhaustiveness-unreachable-pattern.rs:26:9
   |
LL |         (2 | 1, 4) => {}
   |         ^^^^^^^^^^

error: unreachable pattern
  --> $DIR/exhaustiveness-unreachable-pattern.rs:28:9
   |
LL |         (1, 4 | 5) => {}
   | 

to...

error: multiple unreachable patterns
  --> $DIR/exhaustiveness-unreachable-pattern.rs:29:9
   |
LL |         (1, 3) => {}
   |         ^^^^^^^^^^^^ this arm is never executed
...
LL |         (1, 4) => {}
   |         ^^^^^^^^^^^^ this arm is never executed
LL |
LL |         (2, 4) => {}
   |         ^^^^^^^^^^^^ this arm is never executed
LL |
LL |         (2 | 1, 4) => {}
   |         ^^^^^^^^^^^^^^^^ this arm is never executed
...
LL |         (1, 4 | 5) => {}
   |         ^^^^^^^^^^^^^^^^ this arm is never executed

[rustbot]

r? @oli-obk

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

[rustbot]

rustc_error_messages was changed

cc @davidtwco, @compiler-errors, @JohnTitor, @estebank, @TaKO8Ki

[oli-obk]

why are these needed when they weren't before?

Also please attach the attribute to the function instead of using an inner attribute

[mejrs]

Since I changed how the spans work (not entirely sure how/why), it will emit an error like this:

error: unreachable pattern
   --> compiler\rustc_mir_build\src\build\custom\parse.rs:54:13
    |
22  | / macro_rules! parse_by_kind {
23  | |     (
24  | |         $self:ident,
25  | |         $expr_id:expr,
...   |
54  | |             _ => return Err($self.expr_error(expr_id, $expected))
    | |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this arm is never executed
55  | |         }
56  | |     }};
57  | | }
    | |_- in this expansion of `parse_by_kind!`
    |
   ::: compiler\rustc_mir_build\src\build\custom\parse\instruction.rs:146:9
    |
146 | /         parse_by_kind!(self, expr_id, _, "rvalue",
147 | |             @call("mir_discriminant", args) => self.parse_place(args[0]).map(Rvalue::Discriminant),
148 | |             @call("mir_checked", args) => {
149 | |                 parse_by_kind!(self, args[0], _, "binary op",
...   |
171 | |             _ => self.parse_operand(expr_id).map(Rvalue::Use),
    | |             ^ this pattern is irrefutable; subsequent arms are never executed
172 | |         )
    | |_________- in this macro invocation
    |
    = note: `-D unreachable-patterns` implied by `-D warnings`

if it is not allowed in the scope where the macro is invoked.

[oli-obk]

please allow this lint inside the macro instead of at the call sites then.

[mejrs]

I just realized why this happens, it's because I now use the HirId of the scrutinee rather than the match arms, so I guess (the documentation doesn't say) this means the allow attributes now have to be on the match construct itself rather than individual arms.

Actually that seems really undesirable to me so unless there is a way around this that I didn't see, I'm not sure this PR is a good idea.

[oli-obk]

Oh good catch. I guess we could use the hir id of the entire match instead?

[estebank]

We need to run crater to see how this will impact the ecosystem.

[mejrs]

We need to run crater to see how this will impact the ecosystem.

From some basic searches I can tell there will be many matches that will need to shift their allows. Most of them are to deal with conditionally compiling match arms.

[mejrs]

Which I really don't like, actually. I think the allows should remain on the match arms.

[oli-obk]

this may get very verbose for longer arms, maybe keep pointing to the pattern?

[oli-obk]

Looking at the other diagnostic changes I think we should just keep the previous unreachable pattern, considering the other message is so much more helpful now

[mejrs]

What do you mean with "the other message"? I'm afraid I'm not sure what you are proposing.

[mejrs]

Anyway: newbies tend to be more experienced with switch...case structures than pattern matching so I prefer saying "this arm is never executed" over "pattern is unreachable". As for the verbosity it'd be kinda weird to say "this arm is never executed" and just point at the pattern rather than the pattern and the entire code block.

[oli-obk]

I understand that argument, but it is orthogonal to the "make this diagnostic less spammy" change, so I would prefer to discuss it separately with wg-diagnostics, as it seems like a major divergence from existing diagnostics and we'd need to adjust other diagnostics, too.

[estebank]

I'm in agreement with oli's points. We want to make the underlines as short as possible across the board. To address your concern around wording, you could say "this pattern cannot be reached, so its arm is never executed", while pointing only at the pattern. Otherwise, what you can do is have a primary span pointing at the pattern, and a secondary span pointing at the arm. This would be useful for some of the tests cases that involve macros, while still keeping the red underline in VSCode as short as possible.

[mejrs]

Closing because I no longer think this is an improvement. Thanks for the reviews :)