diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2024-04-29 22:37:51 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-04-29 22:37:51 +0200 |
| commit | 42ab090be9b7b1f53c439c3863f05596c5770a00 (patch) | |
| tree | 769bb586f0ad53c767a31ec4e3ce2ae9842f1211 /compiler/rustc_mir_transform/src | |
| parent | 6ce9708ce5fe15f6ece4cc9a50b8fb37561f7cd4 (diff) | |
| parent | c6e946d0f0405fb7641b7dd2cad2d9432e2313f8 (diff) | |
| download | rust-42ab090be9b7b1f53c439c3863f05596c5770a00.tar.gz rust-42ab090be9b7b1f53c439c3863f05596c5770a00.zip | |
Rollup merge of #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 #99380
Diffstat (limited to 'compiler/rustc_mir_transform/src')
0 files changed, 0 insertions, 0 deletions
