This patch makes getLengthToMatchingParen respect the BreakBeforeClosingBrace
ParenState for matching scope closers. In order to distinguish between paren states
introduced by real vs. fake parens, I've added the token opening the ParensState
to that struct.
Details
Diff Detail
- Repository
- rC Clang
Event Timeline
lib/Format/ContinuationIndenter.cpp | ||
---|---|---|
81 | I think this needs a long explanatory comment, possibly with an example of the problem it is actually solving. Also, I am somewhat skeptical as we are using this logic for all paren kinds, not just braces. That seems to be unnecessary work and also might be unexpected at some point (although I cannot come up with a test case where that would be wrong). | |
86 | Maybe pull out a lambda: auto FindParenState = [&](const FormatToken *Tok) { while (MatchingStackIndex >= 0 && Stack[MatchingStackIndex].Tok != &Tok) --MatchingStackIndex; return MatchingStackIndex >= 0 ? &Stack[MatchingStackIndex] : nullptr; }; Then you could write the rest as: ... FindParenState(&Tok); const auto* End = Tok.MatchingParen for (; End->Next; End = End->Next) { if (End->Next->CanBreakBefore || !End->Next->closesScope()) break; auto ParenState = FindParenState(End->Next->MatchingParen); if (ParenState && ParenState.BreakBeforeClosingBrace) break; } return End->TotalLength - Tok.TotalLength + 1; (not entirely sure it's better) | |
lib/Format/ContinuationIndenter.h | ||
215 | The comment should include that this is not considered for memoization as the same state will always be represented by the same token (similar to other below). I wonder whether we should actually move the fields that don't affect memoization out to a different structure at some point. |
Generally looks good.
lib/Format/ContinuationIndenter.cpp | ||
---|---|---|
95 | I r_brace enough? Do we have something similar for TT_ArrayInitializer? I'd look at usages of BreakBeforeClosingBrace to determine. |
lib/Format/ContinuationIndenter.cpp | ||
---|---|---|
95 | Thanks! Based on: |
The comment should include that this is not considered for memoization as the same state will always be represented by the same token (similar to other below). I wonder whether we should actually move the fields that don't affect memoization out to a different structure at some point.