As per https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options, could you please provide more info about the need for this option first?

OK, so this is not a real bug in the sense of non-working current features, it's more like a feature request.
As per https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options, I (and I'm sure other reviewers) would like to understand better this use-case before it's added to clang-format.

In general there's a high bar for adding new style options to clang-format:
https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options

Link to build bot breakage:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/7959/steps/check-llvm%20asan/logs/stdio

Looks good!
I didn't find any instances where this messes-up C++ code (and it looks fine to me for Java code).

In D52676#1251391, @oleg.smolsky wrote:

In D52676#1251342, @krasimir wrote:

Digging a bit further, seems like the behavior you're looking for could be achieved by setting the AlignAfterOpenBracket option to DontAlign or AlwaysBreak:

% clang-format -style='{BasedOnStyle: google, AlignAfterOpenBracket: AlwaysBreak}' test.cc
 void f() {
   something->Method2s(
       1,
       [this] {
         Do1();
         Do2();
       },
       1);
 }
 % clang-format -style='{BasedOnStyle: google, AlignAfterOpenBracket: DontAlign}' test.cc
 void f() {
   something->Method2s(1,
       [this] {
         Do1();
         Do2();
       },
       1);
 }

Does this work for you?

This is interesting. It obviously does what I want with the lambda, but forces this:

void f() {
  auto stub = PopulateContextHereAndHereSomethi(GetSomethingHere(),
                                                GetSomethingElseHere());
}

into this:

void f() {
  auto stub = PopulateContextHereAndHereSomethi(
      GetSomethingHere(), GetSomethingElseHere());
}

The former looks better to me and that's what Emacs does when you press Tab. I think people here at work will balk at this formatting...

I don't think modifying the behavior as posed in this change based on the existence of multiline lambdas and the value of the BinPackArguments option is better than what we have now, especially when AlignAfterOpenBracket=Align.

Yeah, I hear you. The patch is intended to work with AlignAfterOpenBracket=Align and BinPackArguments=false and only tweaks the lambdas' placement.

How about I key the new behavior off a new value of AlignAfterOpenBracket, such as AlignAfterOpenBracket=AlignExceptLambda?

Sorry, I don't think we want to support something this specific. I'd like to hear djasper@ and klimek@ opinions about this.

I'll take a look. I'm a bit worried that this might potentially affect C++ files too: I'll run an experiment over some random files to confirm that we're not missing something.

This gooks great! Thanks for the contribution!
If you don't have commit access to Clang I can commit this for you.

Another example: we have to be careful with something like this as we don't want to break correct code:

import x;
import a.loooooong.
  c;
import y;

Digging a bit further, seems like the behavior you're looking for could be achieved by setting the AlignAfterOpenBracket option to DontAlign or AlwaysBreak:

% clang-format -style='{BasedOnStyle: google, AlignAfterOpenBracket: AlwaysBreak}' test.cc
void f() {
  something->Method2s(
      1,
      [this] {
        Do1();
        Do2();
      },
      1);
}
% clang-format -style='{BasedOnStyle: google, AlignAfterOpenBracket: DontAlign}' test.cc
void f() {
  something->Method2s(1,
      [this] {
        Do1();
        Do2();
      },
      1);
}

• Add more tests and tidy-up

In D52676#1250124, @oleg.smolsky wrote:

In D52676#1250071, @krasimir wrote:

In D52676#1249828, @oleg.smolsky wrote:

In D52676#1249784, @krasimir wrote:

IMO BinPackArguments==false does not imply that there should be a line break before the first arguments, only that there should not be two arguments from the same argument list that appear on the same line.

That's right. However consider the following points:

1. a lambda function is already placed onto its own line when it is the first arg (as you can see in the first test)

I believe that a newline before a first arg lambda is controlled by a different mechanism independent of bin packing, probably by a rule that is more general than just "newline before first arg lambda". I think djasper@ could know more about this case.

Hmm... perhaps. I have not been able to find an explicit rule for that.

1. the other args are placed onto a distinct line
2. this behavior looks very close to "bin packing"
3. adding a new option for the minor cases seems to be an overkill
   
   Having said that, I can add a new explicit style option. Do you think that will improve consensus? Would you expect test cases for positive and negative values of the option?

Not really. It's generally hard to add a new style option, as that is mandated by an existing commonly used public style guide that requires it.

In D52676#1249828, @oleg.smolsky wrote:

In D52676#1249784, @krasimir wrote:

IMO BinPackArguments==false does not imply that there should be a line break before the first arguments, only that there should not be two arguments from the same argument list that appear on the same line.

That's right. However consider the following points:

1. a lambda function is already placed onto its own line when it is the first arg (as you can see in the first test)

I believe that a newline before a first arg lambda is controlled by a different mechanism independent of bin packing, probably by a rule that is more general than just "newline before first arg lambda". I think djasper@ could know more about this case.

1. the other args are placed onto a distinct line
2. this behavior looks very close to "bin packing"
3. adding a new option for the minor cases seems to be an overkill
   
   Having said that, I can add a new explicit style option. Do you think that will improve consensus? Would you expect test cases for positive and negative values of the option?

I don't see how the example before:

void f() {
  something->Method2s(1,
                      [this] {
                        Do1();
                        Do2();
                      },
                      1);
}

is inconsistent, as not adding a newline before the first argument is typical, as in:

$ clang-format -style='{BasedOnStyle: google, BinPackArguments: false}' test.cc                                                             ~
void f() {
  something->Method2s("111111111111111111",
                      "2222222222222222222222222222222222222222222222222222",
                      3);
}

IMO BinPackArguments==false does not imply that there should be a line break before the first arguments, only that there should not be two arguments from the same argument list that appear on the same line.

I don't understand the use-case this patch is realizing. Suppose I have a bunch of projects that have to share a format style. Then I can checkout them under a common root directory and put an appropriate .clang-format file there.

Great! Thanks!

Great! Thank you!

Could you clarify how each piece is supposed to be aligned in these examples?
This is what makes me happy:

// column  limit             V
int a = condition1 ? result1
      : conditio2 ? result2
      : loooooooooocondition 
        ? result2
        : dition3 ? resul3
                  : resul4;

• Address comments

• Address review comments

• Update tests

MarcoFalke: do you need someone to submit this for you?

Thank you!

This breaks CodeGen/WebAssembly/address-offsets.ll. There the typos are intentional, explicitly introduced to disable these cases in r280285. Re-introduced the typos in this file in r336336.

This file is automatically generated from Format.h using clang/docs/tools/dump_format_style.py. Please update.