This avoids mishandling nested compound statements that are followed by another compound statement.
Fixes https://llvm.org/PR38314 and https://llvm.org/PR48305.
Differential D114583
[clang-format] Adjust braced list detection cpplearner on Nov 25 2021, 4:43 AM. Authored by
Details This avoids mishandling nested compound statements that are followed by another compound statement. Fixes https://llvm.org/PR38314 and https://llvm.org/PR48305.
Diff Detail
Unit Tests Event TimelineComment Actions Thanks for working on this. Comment Actions FormatsBracedListsInColumnLayout is actually failing in its own test... it now produces void foo() { { // asdf { int a; } } { { int b; } } } rather than previously void foo() { {// asdf {int a; } } { { int b; } } } Comment Actions The other failure is -class C extends {} {} +class C extends {} +{} I'm slightly struggling to work out in both cases if its the test that is wrong @cpplearner what do you think? Comment Actions For your test I think its your test that is wrong, looking at the simpler versions (using clang-format-12) void foo() { { { int a; } } } void foo() { { int a; } } Comment Actions Fixed tests. Since in JavaScript, the thing after extends must be an expression, and the thing after implements must be an object type, I decided to parse both by directly calling parseBracedList, instead of going through tryToParseBracedList. Comment Actions I ran the examples from https://bugs.llvm.org/show_bug.cgi?id=38314 and its so much better than the previous state! Thanks for this patch, LGTM namespace n { void foo() { { { { statement(); if (false) { } } } {} } } } // namespace n void foo() { { { statement(); if (false) { } } } {} } // namespace n Comment Actions That will be a pain in the ass to merge with my current changes, but looks good. But I second that. Comment Actions Thanks for the update. (You forgot to add the context, but since it was already accepted it's okay.) Comment Actions Thanks! Do you need someone to land this on your behalf? If yes, don't forget to send here your name and email. Comment Actions Yes, I need someone to commit it on my behalf. My name and email address: Tan S. B. <cpplearner@outlook.com> Comment Actions It appears that this regressed the formatting of initializer lists in some cases: # Before % cat ~/test.cc class A { A() : a{} {} A(int b) : b(b) {} A(int a, int b) : a(a), bs{{bs...}} { f(); } int a, b; }; # After % build/bin/clang-format -style=google ~/test.cc class A { A() : a {} {} A(int b) : b(b) {} A(int a, int b) : a(a), bs { { bs... } } { f(); } int a, b; }; @cpplearner could you please take a look? Comment Actions We might want to revert this until we get a solution to avoid flip flopping peoples formats, but this to me comes down to what we've been saying before about using the TT_ types to labels the types of () {} [] I think in hindsight adding l_brace here just too generic (we need to know if its a "BracedInitializer {" or just a scope "{" (NextTok->isOneOf(tok::l_brace, tok::identifier) Comment Actions This is having an impact on code in flang, I don't deny it might be better, but it may not be what is wanted. - explicit Expr(const Scalar<Result> &x) : u{Constant<Result>{x}} {} - explicit Expr(Scalar<Result> &&x) : u{Constant<Result>{std::move(x)}} {} + explicit Expr(const Scalar<Result> &x) : u { + Constant<Result> { x } + } + {} + explicit Expr(Scalar<Result> &&x) : u { + Constant<Result> { std::move(x) } + } + {} |