Nice!

Simplify and generalize the AST matcher. We just want to find all return statements in function definitions.

Add AST matchers for the if statements and improve the actual check implementation.

In D131985#3727568, @Eugene.Zelenko wrote:

In D131985#3727544, @oleg.smolsky wrote:

In D131985#3727436, @njames93 wrote:

The idea of this check is good, but restricting it to only return statements seems baffling. A general check that could remove useless parens would have a lot more value.

Of course a more general check would be more generally useful. Yet that requires a lot more code as handling many more contexts in involved in C++.

Basically this change addresses a concrete, somewhat wide-spread silly habit that exists in the wild.

I recently observed in the wild patterns like:

std::vector<std::string> data;

for (std::vector<std::string>::iterator it = data.begin(); it != data.end(); ++it)
  std::cout << (*it) << std::endl;

Thanks for the quick review, Eugene!

Improve mark up in the docs.

In D131985#3727436, @njames93 wrote:

The idea of this check is good, but restricting it to only return statements seems baffling. A general check that could remove useless parens would have a lot more value.

Add a release note.

Add docs.

Drop the trailing \n from the main C++ file

In D114995#3218022, @aaron.ballman wrote:

In D114995#3218004, @oleg.smolsky wrote:

@aaron.ballman could you commit this change please? I've never had commit rights... Thanks!

Sure can! Is Oleg Smolsky <oleg.smolsky@gmail.com> the correct attribution for the patch, or would you like me to use a different name or email address?

@aaron.ballman could you commit this change please? I've never had commit rights... Thanks!

Done with review changes.

Addressed review comments: explicit types and doc changes.

In D114995#3198033, @aaron.ballman wrote:

In D114995#3183240, @malcolm.parsons wrote:

In D114995#3180475, @aaron.ballman wrote:

was there a reason we didn't cover that case originally or was it an oversight/left for future work?

It was left for future work - by only considering the initializer list of the default constructor, clang-tidy did not have to work out what to do when the constructors don't agree on what value the member init should have.

Thank you for verifying! @oleg.smolsky -- this would be a very useful test case to add, btw.

Added a "two constructors" test case along with the support for that.

Sure, adding an option is easy, if that's the consensus. What would you call it?

@aaron.ballman do you happen to know who is best to review a clang-tidy fix?

Ran clang-format on the test cases.

Ran clang-format

Fixing the uploaded diff...

@MyDeveloperDay that's the exact point. I authored this change to close a gap in some lambda formatting cases. The tests (existing, modified and added) express all relevant cases that I knew at the time.

Sure, I'm OK with the license change. Please go ahead and commit the fix.

Jonas, could you commit the fix please? (I don't have the rights)

:) I thought it would be more productive to post a fix than file a bug.

In D52676#1282335, @krasimir wrote:

Looks good! Will stamp when the scopes are removed.

Folks, are there any other comments/suggestions?

Added a FIXME comment at Krasimir's request.

Corrected test regressions, removed temporary hacks.

Corrected test regressions.

Added another test case.

Generalized the patch so that it deals with lambda args irrespective of bin packing. Added additional tests and patched existing ones.

In D52676#1268806, @djasper wrote:

In D52676#1268748, @oleg.smolsky wrote:

In D52676#1268706, @djasper wrote:

Ok, I think I agree with both of you to a certain extent, but I also think this change as is, is not yet right.

First, it does too much. The original very first example in this CL is actually not produced by clang-format (or if it is, I don't know with which flag combination). It is a case where the lambda is the last parameter.

Right, I cheated and created that example by hand. My apologies for the confusion. I've just pasted real code that I pumped through clang-format. Please take a look at the updated summary.

Second, I agree that the original behavior is inconsistent in a way that we have a special cases for when the lambda is the very first parameter, but somehow seem be forgetting about that when it's not the first parameter. I'd be ok with "fixing" that (it's not a clear-cut bug, but I think the alternative behavior would be cleaner). However, I don't think your patch is doing enough there. I think this should be irrespective of bin-packing (it's related but not quite the same thing),

Also there is a special case for multiple lambdas. It forces line breaks. That aside, for the single-lambda case, are you suggesting that it is always "pulled up", irrespective of its place? That would contradict the direction I am trying to take as I like BinPackArguments: false and so long lamba args go to their own lines. This looks very much in line with what bin packing is, but not exactly the same. Obviously, I can add a new option favor line breaks around multi-line lambda.

I don't think I am. You are right, there is the special case for multi-lambda functions and I think we should have almost the same for single-lambda functions. So, I think I agree with you and am in favor of:

someFunction(
    a,
    [] {
      // ...
    },
    b);

And this is irrespective of BinPacking. I think this is always better and more consistent with what we'd be doing if "a" was not there. The only caveat is that I think with BinPacking true or false, we should keep the more compact formatting if "b" isn't there and the lambda introducer fits entirely on the first line:

someFunction(a, [] {
  // ...
});

In D52676#1268706, @djasper wrote:

Ok, I think I agree with both of you to a certain extent, but I also think this change as is, is not yet right.

First, it does too much. The original very first example in this CL is actually not produced by clang-format (or if it is, I don't know with which flag combination). It is a case where the lambda is the last parameter.

@djasper @klimek could you chime in please? This patch strives to cleanup a quirk in lambda formatting which pushes code too far to the right. Here is the problematic case:

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?

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?

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);
}

Right, it's consistent with your example but inconsistent with with the following two:

lambda at arg0:

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

and two lambdas:

// Multiple lambdas in the same parentheses change indentation rules.
verifyFormat("SomeFunction(\n"
             "    []() {\n"
             "      int i = 42;\n"
             "      return i;\n"
             "    },\n"
             "    []() {\n"
             "      int j = 43;\n"
             "      return j;\n"
             "    });");

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.

Tweaked if/else/return structure, added comments. No functional changes.

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.