================
@@ -528,7 +553,16 @@ void UnwrappedLineParser::calculateBraceTypes(bool
ExpectClassBody) {
Tok->setBlockKind(BK_Block);
}
} else {
- Tok->setBlockKind(BK_Unknown);
+ // In macro bodies we try to keep compound literal expressions like
----------------
Lane0218 wrote:
Thanks for the questions!
Regarding the non-macro path: the mis-formatting reported in #173583 seems to
be specific to macro bodies because the macro replacement text often ends at
`eof` (no trailing `;`, `)`, `,`, etc.), which makes brace-type inference more
likely to misclassify the `{...}` as a block/function body. In “normal” code
(non-macro), a compound literal like `&(type){...}` is typically embedded in a
larger syntactic construct (e.g. followed by `;`, `)`, `,`), so the existing
heuristics tend to classify it as a braced-init already. That’s why I kept the
change restricted to `Line->InMacroBody` to minimize impact outside macros.
On using `MatchingParen`: I agree that using structured pairing information
would be preferable. However, at this point
(`UnwrappedLineParser::calculateBraceTypes`) we run before
`TokenAnnotator::annotate()` (where `MatchingParen` is established), so it
isn’t reliably available here. I’m happy to follow up with a more general
refactor if we want to move this logic to a stage where `MatchingParen` is
guaranteed, but that would be a larger change than this targeted regression fix.
https://github.com/llvm/llvm-project/pull/173771
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
