Rollup merge of rust-lang#103224 - compiler-errors:semi-after-closure-in-macro, r=fee1-dead

Allow semicolon after closure within parentheses in macros

rust-lang#88546 added some parsing logic that if we're parsing a closure, and we're within parentheses, and a semicolon follows, then we must be parsing something erroneous like: `f(|| a; b)`, so it replaces the closure body with an error expression. However, it's valid to parse those tokens if we're within a macro, as in rust-lang#103222.

This is a bit unsatisfying fix. Is there a more robust way of checking that we're within a macro?

I would also be open to removing this "_It is likely that the closure body is a block but where the braces have been removed_" check altogether at the expense of more verbose errors, since it seems very suspicious in the first place...

Fixes rust-lang#103222.

Author: Dylan-DPC

compiler/rustc_parse/src/parser/expr.rs

@@ -2051,6 +2051,10 @@ impl<'a> Parser<'a> {
 
         if self.token.kind == TokenKind::Semi
             && matches!(self.token_cursor.frame.delim_sp, Some((Delimiter::Parenthesis, _)))
+            // HACK: This is needed so we can detect whether we're inside a macro,
+            // where regular assumptions about what tokens can follow other tokens
+            // don't necessarily apply.
+            && self.subparser_name.is_none()
         {
             // It is likely that the closure body is a block but where the
             // braces have been removed. We will recover and eat the next

src/test/ui/parser/semi-after-closure-in-macro.rs

@@ -0,0 +1,14 @@
+// check-pass
+
+// Checks that the fix in #103222 doesn't also disqualify semicolons after
+// closures within parentheses *in macros*, where they're totally allowed.
+
+macro_rules! m {
+    (($expr:expr ; )) => {
+        $expr
+    };
+}
+
+fn main() {
+    let x = m!(( ||() ; ));
+}