This is an archive of the discontinued LLVM Phabricator instance.

[clang-format] Fix AlignConsecutiveAssignments breaking lambda formatting.
ClosedPublic

Authored by curdeius on Dec 17 2021, 2:32 PM.

Details

Summary

Fixes https://github.com/llvm/llvm-project/issues/52772.

This patch fixes the formatting of the code:

auto aaaaaaaaaaaaaaaaaaaaa = {};
auto b                     = g([] {
  return;
});

which should be left as is, but before this patch was formatted to:

auto aaaaaaaaaaaaaaaaaaaaa = {};
auto b                     = g([] {
  return;
                    });

Diff Detail

Event Timeline

curdeius requested review of this revision.Dec 17 2021, 2:32 PM
curdeius created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptDec 17 2021, 2:32 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
This revision is now accepted and ready to land.Dec 17 2021, 2:40 PM
curdeius planned changes to this revision.Dec 17 2021, 2:43 PM

Actually, I've just run it on a larger codebase and found that this patch misbehaves. Need to rework and add faulty test cases.
Sorry for the noise.

curdeius updated this revision to Diff 404431.Jan 31 2022, 12:19 AM

Fix cases with lambdas. Added a (still) failing test with a ternary operator and multi-line continuation.

This revision is now accepted and ready to land.Jan 31 2022, 12:19 AM

This is still a WIP, but I'd like to have your opinion on how to tackle this problem.
What I'd like to do basically is to avoid shifting right the body of the lambda but still align things inside the lambda body.
This patch, for the moment, basically disables alignment in the lambdas which is not what I want.
Also, this approach is ugly.

All these problems were introduced somewhere between release 12 and 13. Does anyone know which commit could provoke this?

clang/unittests/Format/FormatTest.cpp
16605

This test case still fails, but I'm inclined to keep it commented for the moment and fix it later.

curdeius requested review of this revision.Jan 31 2022, 12:24 AM

This patch, for the moment, basically disables alignment in the lambdas which is not what I want.

I sort of feel that's ok for now.

This is still a WIP, but I'd like to have your opinion on how to tackle this problem.

What are we trying to achieve? what is the expected output if not this? From what I can tell what you've put in your lists it looks ok

auto aaaaaaaaaaaaaaaaaaaaa = {};
auto b                     = g([] {
  return;
});

This patch, for the moment, basically disables alignment in the lambdas which is not what I want.

I sort of feel that's ok for now.

Ok.

This is still a WIP, but I'd like to have your opinion on how to tackle this problem.

What are we trying to achieve? what is the expected output if not this? From what I can tell what you've put in your lists it looks ok

auto aaaaaaaaaaaaaaaaaaaaa = {};
auto b                     = g([] {
  return;
});

The expected output is ok indeed, I'm rather not sure about the way I solve it here.

But yeah, it's better than what we have now.

curdeius updated this revision to Diff 404438.Jan 31 2022, 1:35 AM
  • Add FIXME.
clang/unittests/Format/FormatTest.cpp
16608

What determines this indent? I can't see how it should be calculated.

curdeius added inline comments.Jan 31 2022, 4:28 AM
clang/unittests/Format/FormatTest.cpp
16608

I didn't think about it before. But now I see, it's computed as in:

verifyFormat("auto b = f(aaaaaaaaaaaaaaaaaaaaaaaaa,\n"
             "           ccc ? aaaaa : bbbbb,\n"
             "           dddddddddddddddddddddddddd);",
             Alignment);

i.e. as if there were no alignment at = sign. So it's "aligned" to the previous position just after of f(.

Maybe we should align it the same way we do when function arguments don't fit into the line?
Note, I opened https://github.com/llvm/llvm-project/issues/53497 for it.

HazardyKnusperkeks added inline comments.
clang/unittests/Format/FormatTest.cpp
16608

Maybe we should align it the same way we do when function arguments don't fit into the line?

Yes we should. (Next line and add ContinuationIndent, should it be, right?)

But yes, that could be handled in a different commit.

This revision is now accepted and ready to land.Jan 31 2022, 11:32 AM
This revision was landed with ongoing or failed builds.Feb 1 2022, 12:18 AM
This revision was automatically updated to reflect the committed changes.