-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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.
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
Fix, document, and test parser and pretty-printer edge cases related to braced macro calls #119427
Commits on May 11, 2024
-
Configuration menu - View commit details
-
Copy full SHA for b431eec - Browse repository at this point
Copy the full SHA b431eecView commit details -
Mark expr_requires_semi_to_be_stmt call sites
For each of these, we need to decide whether they need to be using `expr_requires_semi_to_be_stmt`, or `expr_requires_comma_to_be_match_arm`, which are supposed to be 2 different behaviors. Previously they were conflated into one, causing either too much or too little parenthesization.
Configuration menu - View commit details
-
Copy full SHA for cbb8714 - Browse repository at this point
Copy the full SHA cbb8714View commit details -
Macro call with braces does not require semicolon to be statement
This commit by itself is supposed to have no effect on behavior. All of the call sites are updated to preserve their previous behavior. The behavior changes are in the commits that follow.
Configuration menu - View commit details
-
Copy full SHA for 9e1cf20 - Browse repository at this point
Copy the full SHA 9e1cf20View commit details -
Configuration menu - View commit details
-
Copy full SHA for c5a0eb1 - Browse repository at this point
Copy the full SHA c5a0eb1View commit details -
Configuration menu - View commit details
-
Copy full SHA for 7f2ffbd - Browse repository at this point
Copy the full SHA 7f2ffbdView commit details -
Delete MacCall case from pretty-printing semicolon after StmtKind::Expr
I didn't figure out how to reach this condition with `expr` containing `ExprKind::MacCall`. All the approaches I tried ended up with the macro call ending up in the `StmtKind::MacCall` case below instead. In any case, from visual inspection this is a bugfix. If we do end up with a `StmtKind::Expr` containing `ExprKind::MacCall` with brace delimiter, it would not need ";" printed after it.
Configuration menu - View commit details
-
Copy full SHA for d9bb733 - Browse repository at this point
Copy the full SHA d9bb733View commit details -
Configuration menu - View commit details
-
Copy full SHA for 0ca322c - Browse repository at this point
Copy the full SHA 0ca322cView commit details -
Configuration menu - View commit details
-
Copy full SHA for c6c18a0 - Browse repository at this point
Copy the full SHA c6c18a0View commit details -
Configuration menu - View commit details
-
Copy full SHA for 4a80865 - Browse repository at this point
Copy the full SHA 4a80865View commit details -
Configuration menu - View commit details
-
Copy full SHA for 8adcaf5 - Browse repository at this point
Copy the full SHA 8adcaf5View commit details -
Configuration menu - View commit details
-
Copy full SHA for 9dbe33d - Browse repository at this point
Copy the full SHA 9dbe33dView commit details -
Configuration menu - View commit details
-
Copy full SHA for 728e117 - Browse repository at this point
Copy the full SHA 728e117View commit details -
Configuration menu - View commit details
-
Copy full SHA for 0f6a51d - Browse repository at this point
Copy the full SHA 0f6a51dView commit details -
Remove MacCall special case from recovery after missing 'if' after 'e…
…lse' The change to the test is a little goofy because the compiler was guessing "correctly" before that `falsy! {}` is the condition as opposed to the else body. But I believe this change is fundamentally correct. Braced macro invocations in statement position are most often item-like (`thread_local! {...}`) as opposed to parenthesized macro invocations which are condition-like (`cfg!(...)`).
Configuration menu - View commit details
-
Copy full SHA for aedc1b6 - Browse repository at this point
Copy the full SHA aedc1b6View commit details -
Remove MacCall special cases from Parser::parse_full_stmt
It is impossible for expr here to be a braced macro call. Expr comes from `parse_stmt_without_recovery`, in which macro calls are parsed by `parse_stmt_mac`. See this part: let kind = if (style == MacStmtStyle::Braces && self.token != token::Dot && self.token != token::Question) || self.token == token::Semi || self.token == token::Eof { StmtKind::MacCall(P(MacCallStmt { mac, style, attrs, tokens: None })) } else { // Since none of the above applied, this is an expression statement macro. let e = self.mk_expr(lo.to(hi), ExprKind::MacCall(mac)); let e = self.maybe_recover_from_bad_qpath(e)?; let e = self.parse_expr_dot_or_call_with(e, lo, attrs)?; let e = self.parse_expr_assoc_with( 0, LhsExpr::AlreadyParsed { expr: e, starts_statement: false }, )?; StmtKind::Expr(e) }; A braced macro call at the head of a statement is always either extended into ExprKind::Field / MethodCall / Await / Try / Binary, or else returned as StmtKind::MacCall. We can never get a StmtKind::Expr containing ExprKind::MacCall containing brace delimiter.
Configuration menu - View commit details
-
Copy full SHA for 53521fa - Browse repository at this point
Copy the full SHA 53521faView commit details
Commits on May 12, 2024
-
Configuration menu - View commit details
-
Copy full SHA for 10227ea - Browse repository at this point
Copy the full SHA 10227eaView commit details -
Configuration menu - View commit details
-
Copy full SHA for 78c8dc1 - Browse repository at this point
Copy the full SHA 78c8dc1View commit details