Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Confusing "arbitrary expressions aren't allowed in patterns" error #99380

Closed
est31 opened this issue Jul 17, 2022 · 2 comments · Fixed by #124488
Closed

Confusing "arbitrary expressions aren't allowed in patterns" error #99380

est31 opened this issue Jul 17, 2022 · 2 comments · Fixed by #124488
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) D-terse Diagnostics: An error or lint that doesn't give enough information about the problem at hand. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@est31
Copy link
Member

est31 commented Jul 17, 2022

Take the following code:

macro_rules! foo {
    ($p:expr) => {
        if let $p = Some(42) {
            return;
        }
    };
}

fn main() {
    foo!(Some(3));
}

Currently it fails with:

error: arbitrary expressions aren't allowed in patterns
  --> src/main.rs:10:10
   |
10 |     foo!(Some(3));
   |          ^^^^^^^

If you expanded the macro manually, Some(3) would be parsed as a pattern, but the $p:expr above changes it to be parsed as an expression. So what you need to do here is to change the $p:expr above to $p:pat. But this is very non-obvious.

Ideally, the compiler would try to check if the input is a valid pattern, and if so, add a note like "Some(3) is a valid pattern but the metavariable $p is specified to be an expression", and maybe also point to the metavariable's matcher.

@rustbot label A-macros
@est31 est31 added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 17, 2022
@rustbot rustbot added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label Jul 17, 2022
@alexpetros
Copy link

Finding this issue saved me a lot of time, and I think adding this error to the compiler would help!

@fmease fmease added the D-terse Diagnostics: An error or lint that doesn't give enough information about the problem at hand. label Apr 24, 2024
@est31
Copy link
Member Author

est31 commented Apr 26, 2024

I've looked into this and adding an error message is harder than I thought. The issue is that the span provided to the lower_expr_within_pat function is already resolved to the original location of the Some(3) so calling .from_expansion() isn't going to help much.

I can add a check like is_approximately_pattern or something, but it then causes basically anything to be recognized, even if it has never been from a macro matcher, so usually the hint would be a false positive.

@est31 est31 mentioned this issue Apr 28, 2024
Merged
@bors bors closed this as completed in 42ab090 Apr 30, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 30, 2024
@rust-timer
Unrolled build for rust-lang#124488
54f4008 
Rollup merge of rust-lang#124488 - est31:arbitrary_expressions_error, r=pnkfelix

Add a note to the ArbitraryExpressionInPattern error

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 rust-lang#99380
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) D-terse Diagnostics: An error or lint that doesn't give enough information about the problem at hand. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add a note to the ArbitraryExpressionInPattern error est31/rust
4 participants
@est31 @fmease @alexpetros @rustbot