Add a note to the ArbitraryExpressionInPattern error

[est31]

The current "arbitrary expressions aren't allowed in patterns" error is confusing, as it fires for code where it looks like a pattern but the compiler still treats it as an expression. That this is due to the :expr fragment specifier forcing the expression-ness property on the code.

In the test suite, the "arbitrary expressions aren't allowed in patterns" error can only be found in combination with macro_rules macros that force expression-ness of their content, namely via :expr metavariables. I also can't come up with cases where there would be an expression instead of a pattern, so I think it's always coming from an :expr.

In order to make the error less confusing, this adds a note explaining the weird :expr fragment behaviour.

Fixes #99380

[rustbot]

r? @pnkfelix

rustbot has assigned @pnkfelix.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[est31]

I also can't come up with cases where there would be an expression instead of a pattern

Note that should in the future anyone discover cases where there was no involvement of :expr fragment specifiers, we can still change the wording or make it dependent on fragment specifiers being present.

[pnkfelix]

#99380 is interesting. It seems like the intent was to signal that the macro definition itself is ill-formed, but the error reporting machinery is only firing after the macro itself is invoked, and only highlights the macro invocation site, rather than saying anything at all about the macro definition.

Does that sound like a reasonable synopsis of what problem the error message itself was trying to address, @est31 ?

[pnkfelix]

@bors r+ rollup

[bors]

📌 Commit c6e946d has been approved by pnkfelix

It is now in the queue for this repository.

[est31]

@pnkfelix

It seems like the intent was to signal that the macro definition itself is ill-formed, but the error reporting machinery is only firing after the macro itself is invoked, and only highlights the macro invocation site, rather than saying anything at all about the macro definition.

I don't know what the original intent of the error was but in many cases, the usual way to resolve is indeed to change the fragment specifier from expr to something more generic like tt. Sometimes the expr property is intended, like for the vec![] macro used in patterns for example.

Before this patch, the error message was extremely terse and would cause a lot of confusion as to why it's an expression and not a pattern. Now, it at least mentions fragment specifiers.

I could have made it point to the fragment specifier but the only way I could find would involve changing both the token and AST format to include the additional data: not sure it's worth that. I have it in this branch.

error: arbitrary expressions aren't allowed in patterns
  --> $DIR/issue-99380.rs:10:10
   |
LL |     foo!(Some(3));
   |          ^^^^^^^
   |
note: the expression looks like a pattern but it comes from an `:expr` meta variable
  --> $DIR/issue-99380.rs:2:7
   |
LL |     ($p:expr) => {
   |       ^

error: aborting due to 1 previous error