<div dir="ltr">Hi Daniel,<div><br></div><div>Thanks, I understand why your users would have requested that and why you need to provide this improvement for them.</div><div>I will survey the other people writing code with me on whether they are happy with this improvement considering both the readability of the statements and the relatively small impact in our day to day reading/writing.</div><div>I'll get back to you, maybe I was wasting time on a non issue..</div><div><br></div><div>Cheers,</div><div>Jean-Philippe.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-28 9:51 GMT+01:00 Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Jean-Philippe,<div><br></div><div>no, you have not convinced me with those examples. There is not a single one, I find more readable. Many of them I find equally unreadable and would write the code differently. But I would never have chose AlwaysBreak for my own code in the first place and I rarely work in a codebase that uses it. When I do, it usually bugs me. So, that (my opinion) is completely beside the point.</div><div><br></div><div>There is one fundamental half-way objective argument you can make here (and in many other cases): Being more compact generally makes it easier to read larger chunks of code as it is more likely for a whole function/loop/... to fit on a single page. Using more linebreaks to make the syntactic structure clearer and more uniform can make individual statements more readable. My argument is that in this case, often many lines are saved with very little to no impact on local readability. You disagree and that's fine, I am not trying to convince you. People a different here.</div><div><br></div><div>If you need the uniformity so that many subsequent statements are formatted equally (e.g. in your "<span style="font-size:12.8px">connRegist.Add(</span><span style="font-size:12.8px"> ..." case), you are likely doing it wrong. Try harder not to repeat yourself. The problem here is that such uniformly appearing sequence can hide very subtle (copy&paste) errors. However, even all of this is beside the point.</span></div><div><br></div><div>You found changes in ~10% of your files. I'd bet that less than 10% of a file was changed on average. So, this influences <1% of the code. That is reasonably rare and you won't stumble over this frequently in practice. Yes, of course you see hundreds of examples when you reformat a thousand-file codebase and I understand why that bugs you.<br></div><div><br></div><div>I definitely need the new behavior as it was requested frequently by my internal users. This was the most frequent bug report I have gotten from people using AlwaysBreak. I suggest that you also speak to the other authors of the codebase you are working on to make sure that you are actually getting a feel for what most people want here. And also include cases where it is significantly better IMO:</div><div><br></div><div> call(call(call(call(call(call(call(call(call(call(call(</div><div> parameterThatGoesUpToTheColumnLimit)))))))))));</div><div><br></div><div>vs.</div><div><br></div><div> call(</div><div> call(</div><div><div> call(</div><div> call(</div></div><div> ...</div><div> parameterThatGoesUpToTheColumnLimit))))))))))); // probably even a column limit violation</div><div><br></div><div>Again, I am not against adding an additional option. And if we do introduce a new option, we should probably make that one strict and not have the other exceptions.</div><div><br></div><div>Cheers,<br>Daniel</div><div> </div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 27, 2016 at 8:16 PM, Jean-philippe Dufraigne <span dir="ltr"><<a href="mailto:j.dufraigne@gmail.com" target="_blank">j.dufraigne@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Daniel,<div><br></div><div>Thanks a lot for your answer and clarifications.</div><div>Sorry for the long answer, TLDR at the beginning (and end for code examples).</div><div><br></div><div>To answer your 2 questions immediately:</div><div>- It happens a lot more than I thought, about 10% of the few thousands file I checked had instances of this.</div><div>- Yes, there is a significant readability <span style="font-size:12.8px">disadvantage as these functions become a special case that needs to be read differently from all the other functions.</span><br></div><div><span style="font-size:12.8px"> With consistent AlwaysBreak, it is obvious from the shape of the call how to read it (horizontally or diagonally).</span></div><div><span style="font-size:12.8px"> Now, it is not longer obvious and it impact readability mostly for these functions, but also a bit for the other functions since it is not clear if they are one of the special case or not.</span></div><div><span style="font-size:12.8px"> (The eye needs to jump at the end and then back to parse the arguments)</span></div><div><span style="font-size:12.8px"> (This ls less/not of an issue for lambda and small functions)</span></div><div><br></div><div><br></div><div>My conclusion:</div><div><div>I really think an option should provide a consistent break but I'm really not sure it should be a new option.</div><div>If I manage to convince you through the examples, that formatting all function consistently will actually improve overall readability more generally, I think AlwaysBreak is just fine as it was.</div></div><div><div>I'm happy to help with coding or writing tests for whatever decision you make.</div></div><div><br></div><div><br></div><div>Examples:</div><div><span style="font-size:12.8px">I've pasted / attached the code examples that I saw, some many many times (with .clang-format file).</span></div><div><div>You'll be able to see how before things were more consistent and now things are moved to unexpected places depending on the call.</div></div><div>Moreover the benefit is very limited for us, because gaining 1 line does not seem to add to our readability, and the indentation saved (most often 1 (4 spaces)) does not lead to better or different arguments formatting in most cases. (less than 10 where arguments where improved in the hundreds of cases I've looked at).</div><div><br></div><div><br></div><div>Methodology:</div><div><div>I wanted to make sure that I really understood the problem before coming back to you:</div></div><div>- I've done a full reformat of 2 of our projects first with snapshot r260967, then with snapshot r264047 (with the new change).<br></div><div> That is few thousands of cpp/h files, and about 10% were modified when running the updated format.</div><div>- I spent more hours than I should have yesterday just scrolling through and taking notes in a 30'000 line diff of the impact of the update (using 10 lines of context), so I think I've got a good handle on the issue now.<br></div><div><br></div><div><br></div><div>Other comments:</div><div>- It is possible that with some other configuration you used, this change does improves things without the same draw back, I do not know, but your commit comment example did not look more readable for me since I am used to the style.</div><div>- lambda break would be nice and more what we would have expected, but they are somewhat a different thing and less of a problem.</div><div>- Very small function break occurs not that often and are weird to format either way. They are also less of an issue because they are small so everything is mostly where the eye is looking at (no need for the eye to jump toward the end of the line and back).</div><div>- I also think the new option as you described could have some trickiness, it may also impact things like 'if' if we are not careful, and it is also another maintenance burden.</div><div><br></div><div><br></div><div><br></div><div>Other notes / detailed explanations:</div><div><br></div><div><div>1 - With a consistent always break, there are 2 places you have too look for, and the one your need is obvious from the shape of the code:<br></div><div> - Either it is multi-line, and 1st argument is described at the indentation => Scan function call diagonally</div><div> - Or it is a single line call and the 1st argument is described after the '(' => Scan function horizontally</div><div><br></div><div>With this new formatting, the 1st argument may also start to be described after the '(' and then continue at the indentation.</div><div>It is no longer possible to scan diagonally, and that really apply for any functions as it is not obvious from the shape of the call.</div></div><div><br></div><div>2 - It may be because of our other style options, but there are very few (less than 10 in the many hundreds) where the result could be said to be better, on its own:</div><div>This happens, because we most often only gain a new line (not really an improvement for us) and only one indentation (4 spaces), and the odds that the argument is too big by between 1 and 4 spaces is not so great:</div><div>So the net result is that the argument are shifted 4 spaces to the left without really any improvements.</div><div><br></div><div>3- There is one unrelated bug with unstable comment re flowing in macros that I found as a result and will try to raise it.</div><div> There was also some minor changes in the way few 'else if' were formatted but this is not the main matter.</div><div> There was also an issue with formatting a template call with explicit types as a function argument indented strangely.</div><div><br></div><div>Cheers,</div><div>Jean-Philippe</div><div><br></div><div><br></div><div><br></div><div>NewTest.cpp (also attached, contains both code reformatted with r26096 and with r264047):</div><div>You can see how before things were more consistent and now things are moved to unexpected places depending on the call.</div><div><br></div><div><div>class TestClass1</div><div>{</div><div> //</div><div> // Before:</div><div> //</div><div> typedef boost::multi_index_container<</div><div> DataRecordPtr,</div><div> mi::indexed_by<</div><div> mi::ordered_unique<</div><div> mi::const_mem_fun<</div><div> Type00000001,</div><div> Type00000000002,</div><div> &Type00000001::Fct > >,</div><div> mi::ordered_non_unique<</div><div> mi::const_mem_fun<</div><div> Type000003,</div><div> Type00004,</div><div> &Type000003::Fct0002 > > > ></div><div> TypedefName0000;</div><div><br></div><div> typedef boost::function<</div><div> StaticClass01::TypeOfReturnValue0001( ParamType1* ) ></div><div> TypedefName0000000001;</div><div><br></div><div> typedef boost::function<</div><div> std::wstring(</div><div> int,</div><div> ClassName000001::Value00000001,</div><div> const std::wstring& ) ></div><div> TypedefName000000000002;</div><div><br></div><div> //</div><div> // After r264047:</div><div> //</div><div> typedef boost::multi_index_container<</div><div> DataRecordPtr,</div><div> mi::indexed_by<</div><div> mi::ordered_unique< mi::const_mem_fun<</div><div> Type00000001,</div><div> Type00000000002,</div><div> &Type00000001::Fct > >,</div><div> mi::ordered_non_unique< mi::const_mem_fun<</div><div> Type000003,</div><div> Type00004,</div><div> &Type000003::Fct0002 > > > ></div><div> TypedefName0000;</div><div><br></div><div> typedef boost::function< StaticClass01::TypeOfReturnValue0001(</div><div> ParamType1* ) ></div><div> TypedefName0000000001;</div><div><br></div><div> typedef boost::function< std::wstring(</div><div> int,</div><div> ClassName000001::Value00000001,</div><div> const std::wstring& ) ></div><div> TypedefName000000000002;</div><div>};</div><div><br></div><div>void Test1()</div><div>{</div><div> //</div><div> // Before:</div><div> //</div><div> connRegist.Add(</div><div> member1->ConnectSignal00001(</div><div> boost::bind( &ThisClassNme::Callback00001, this, _1 ) ) );</div><div> connRegist.Add(</div><div> member1->ConnectSignal00002(</div><div> boost::bind( &ThisClassNme::Callback000000002, this ) ) );</div><div> connRegist.Add(</div><div> member1->ConnectSignal00003(</div><div> boost::bind( &ThisClassNme::Callback0000003, this, _1 ), true ) );</div><div> connRegist.Add(</div><div> member1->ConnectSignal00004(</div><div> boost::bind(</div><div> &ThisClassNme::Callback00000000000000000000000004, this ) ) );</div><div> connRegist.Add(</div><div> member1->ConnectSignal00003(</div><div> boost::bind(</div><div> &ThisClassNme::Callback00000000000000000000000005, this, _1 ),</div><div> true ) );</div><div><br></div><div> //</div><div> // After r264047:</div><div> //</div><div> connRegist.Add( member1->ConnectSignal00001(</div><div> boost::bind( &ThisClassNme::Callback00001, this, _1 ) ) );</div><div> connRegist.Add( member1->ConnectSignal00002(</div><div> boost::bind( &ThisClassNme::Callback000000002, this ) ) );</div><div> connRegist.Add( member1->ConnectSignal00003(</div><div> boost::bind( &ThisClassNme::Callback0000003, this, _1 ), true ) );</div><div> connRegist.Add( member1->ConnectSignal00004( boost::bind(</div><div> &ThisClassNme::Callback00000000000000000000000004, this ) ) );</div><div> connRegist.Add( member1->ConnectSignal00003(</div><div> boost::bind(</div><div> &ThisClassNme::Callback00000000000000000000000005, this, _1 ),</div><div> true ) );</div><div>}</div><div>void Test1()</div><div>{</div><div> //</div><div> // Before:</div><div> //</div><div> CPPUNIT_ASSERT_NO_THROW(</div><div> object.member00000001->Function1( L"string0000001", L"string002" ) );</div><div><br></div><div> // The different one after:</div><div> CPPUNIT_ASSERT(</div><div> object.member0002->Function000002(</div><div> object.member00000001->Function000000002() ) );</div><div><br></div><div> CPPUNIT_ASSERT_THROW(</div><div> object.member00000001->Function1( L"strin", L"string03" ),</div><div> ExpecException );</div><div><br></div><div> //</div><div> // After r264047:</div><div> //</div><div> CPPUNIT_ASSERT_NO_THROW(</div><div> object.member00000001->Function1( L"string0000001", L"string002" ) );</div><div><br></div><div> // The different one after:</div><div> CPPUNIT_ASSERT( object.member0002->Function000002(</div><div> object.member00000001->Function000000002() ) );</div><div><br></div><div> CPPUNIT_ASSERT_THROW(</div><div> object.member00000001->Function1( L"strin", L"string03" ),</div><div> ExpecException );</div><div>}</div><div><br></div><div>void Test2()</div><div>{</div><div> //</div><div> // Before:</div><div> //</div><div> boost::scoped_ptr< Type01 > obj001(</div><div> new Type01(</div><div> nsp::nmspc::ServiceInfoPtr(</div><div> new nsp::nmspc::TypeInfo001(</div><div> key,</div><div> key,</div><div> nsp::Conver< std::string >( objectName ),</div><div> nsp::nmspc::nmspace::Value000001,</div><div> nsp::nmspc::nmspace::Value002 ) ),</div><div> extraArg001 ) );</div><div><br></div><div> boost::scoped_ptr< Type01 > obj002(</div><div> new Type01(</div><div> nsp::nmspc::TypeInfo001Ptr(</div><div> new nsp::nmspc::TypeInfo001(</div><div> key,</div><div> key,</div><div> nsp::Conver< std::string >( objectName ),</div><div> nsp::nmspc::nmspace::Value000001,</div><div> nsp::nmspc::nmspace::Value002 ) ) ) );</div><div><br></div><div> //</div><div> // After r264047:</div><div> //</div><div> boost::scoped_ptr< Type01 > obj001( new Type01(</div><div> nsp::nmspc::ServiceInfoPtr( new nsp::nmspc::TypeInfo001(</div><div> key,</div><div> key,</div><div> nsp::Conver< std::string >( objectName ),</div><div> nsp::nmspc::nmspace::Value000001,</div><div> nsp::nmspc::nmspace::Value002 ) ),</div><div> extraArg001 ) );</div><div><br></div><div> boost::scoped_ptr< Type01 > obj002(</div><div> new Type01( nsp::nmspc::TypeInfo001Ptr( new nsp::nmspc::TypeInfo001(</div><div> key,</div><div> key,</div><div> nsp::Conver< std::string >( objectName ),</div><div> nsp::nmspc::nmspace::Value000001,</div><div> nsp::nmspc::nmspace::Value002 ) ) ) );</div><div>}</div><div><br></div><div>void Test3</div><div>{</div><div> {</div><div> {</div><div> //</div><div> // Before:</div><div> //</div><div> memberObject0000000001.reset(</div><div> new nmspc::namespc::scoped_register01(</div><div> object00001->ConnectToSomeEvent0001(</div><div> boost::bind(</div><div> &namespc00001::ClassName0000001::FunctionName00001,</div><div> this,</div><div> _1 ) ) ) );</div><div><br></div><div> //</div><div> // After r264047:</div><div> //</div><div> memberObject0000000001.reset( new nmspc::namespc::scoped_register01(</div><div> object00001->ConnectToSomeEvent0001( boost::bind(</div><div> &namespc00001::ClassName0000001::FunctionName00001,</div><div> this,</div><div> _1 ) ) ) );</div><div> }</div><div> }</div><div>}</div></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-24 20:20 GMT+00:00 Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Jean-Philippe,<div><br></div><div>first off, sorry that this is causing you trouble.</div><div><br></div><div>I am always happy to reconsider. However, I do think that this is a good change based on hundreds of examples I have looked at. Obviously, this is subjective and I won't even start to make an argument on whether this is wasted or not.</div><div><br></div><div>We could add a separate option, but it is not quite as easy. AlwaysBreak has never been *always* break. There have always been exceptions. Two immediately spring to mind:</div><div>1. When the function name (plus open parenthesis) is shorter or equal to the ContinuationIndentWidth.</div><div>2. For nested blocks such as lambdas, at least in some of the cases.</div><div><br></div><div>Both are also about wasting space. I think single argument function calls are closely related to those two. So, we could add an "StrictAlwaysBreak" mode and then also not have the two exemptions above, but I am not sure it is worth it.</div><div><div class="gmail_extra"><br></div><div class="gmail_extra">How often do these cases occur in your codebase? Do you really feel like there is a significant readability disadvantage?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Daniel</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 20, 2016 at 12:00 PM, Jean-philippe Dufraigne <span dir="ltr"><<a href="mailto:j.dufraigne@gmail.com" target="_blank">j.dufraigne@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Daniel,<div><br></div><div><div>I'm not sure I understand the logic behind modifying 'AlwaysBreak' to be 'AlwaysBreakExceptForSingleArgument'.</div><div><br></div><div>AlwaysBreak is always going to lead to "wasted space".</div><div>Some consider consistently break to not be a waste but actually contribute to readability, it seems that was what 'AlwaysBreak' was about.<br></div><div><br></div><div>Would you reconsider this change, or make it an option different from 'AlwaysBreak'?</div></div><div><br></div><div><br></div><div><br></div><div>We just completed the roll out clang-format at my company.</div><div><div>We are using: AlignAfterOpenBracket: AlwaysBreak</div></div><div>We tuned the settings to have a style that does not clash too much with our original style, and that will look like a regression for us.<br></div><div><br></div><div>Kind regards,</div><div>Jean-Philippe.</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-17 12:00 GMT+00:00 Daniel Jasper via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Author: djasper<br>
Date: Thu Mar 17 07:00:22 2016<br>
New Revision: 263709<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=263709&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=263709&view=rev</a><br>
Log:<br>
clang-format: Slightly weaken AlignAfterOpenBracket=AlwaysBreak.<br>
<br>
If a call takes a single argument, using AlwaysBreak can lead to lots<br>
of wasted lines and additional indentation without improving the<br>
readability in a significant way.<br>
<br>
Before:<br>
caaaaaaaaaaaall(<br>
caaaaaaaaaaaall(<br>
caaaaaaaaaaaall(<br>
caaaaaaaaaaaaaaaaaaaaaaall(aaaaaaaaaaaaaa, aaaaaaaaa))));<br>
<br>
After:<br>
caaaaaaaaaaaall(caaaaaaaaaaaall(caaaaaaaaaaaall(<br>
caaaaaaaaaaaaaaaaaaaaaaall(aaaaaaaaaaaaaa, aaaaaaaaa))));<br>
<br>
Modified:<br>
cfe/trunk/lib/Format/ContinuationIndenter.cpp<br>
cfe/trunk/unittests/Format/FormatTest.cpp<br>
<br>
Modified: cfe/trunk/lib/Format/ContinuationIndenter.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=263709&r1=263708&r2=263709&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=263709&r1=263708&r2=263709&view=diff</a><br>
==============================================================================<br>
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)<br>
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Thu Mar 17 07:00:22 2016<br>
@@ -356,7 +356,17 @@ void ContinuationIndenter::addTokenOnCur<br>
Previous.isOneOf(tok::l_paren, TT_TemplateOpener, tok::l_square) &&<br>
State.Column > getNewLineColumn(State) &&<br>
(!Previous.Previous ||<br>
- !Previous.Previous->isOneOf(tok::kw_for, tok::kw_while, tok::kw_switch)))<br>
+ !Previous.Previous->isOneOf(tok::kw_for, tok::kw_while,<br>
+ tok::kw_switch)) &&<br>
+ // Don't do this for simple (no expressions) one-argument function calls<br>
+ // as that feels like needlessly wasting whitespace, e.g.:<br>
+ //<br>
+ // caaaaaaaaaaaall(<br>
+ // caaaaaaaaaaaall(<br>
+ // caaaaaaaaaaaall(<br>
+ // caaaaaaaaaaaaaaaaaaaaaaall(aaaaaaaaaaaaaa, aaaaaaaaa))));<br>
+ Current.FakeLParens.size() > 0 &&<br>
+ Current.FakeLParens.back() > prec::Unknown)<br>
State.Stack.back().NoLineBreak = true;<br>
<br>
if (Style.AlignAfterOpenBracket != FormatStyle::BAS_DontAlign &&<br>
<br>
Modified: cfe/trunk/unittests/Format/FormatTest.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=263709&r1=263708&r2=263709&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=263709&r1=263708&r2=263709&view=diff</a><br>
==============================================================================<br>
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)<br>
+++ cfe/trunk/unittests/Format/FormatTest.cpp Thu Mar 17 07:00:22 2016<br>
@@ -4461,12 +4461,31 @@ TEST_F(FormatTest, AlignsAfterOpenBracke<br>
" aaaaaaaaaaa aaaaaaaaa,\n"<br>
" aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);",<br>
Style);<br>
- verifyFormat("SomeLongVariableName->someFunction(\n"<br>
- " foooooooo(\n"<br>
- " aaaaaaaaaaaaaaa,\n"<br>
- " aaaaaaaaaaaaaaaaaaaaa,\n"<br>
- " aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa));",<br>
+ verifyFormat("SomeLongVariableName->someFunction(foooooooo(\n"<br>
+ " aaaaaaaaaaaaaaa,\n"<br>
+ " aaaaaaaaaaaaaaaaaaaaa,\n"<br>
+ " aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa));",<br>
Style);<br>
+ verifyFormat(<br>
+ "aaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaa(\n"<br>
+ " aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaa)));",<br>
+ Style);<br>
+ verifyFormat(<br>
+ "aaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaa.aaaaaaaaaa(\n"<br>
+ " aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaa)));",<br>
+ Style);<br>
+ verifyFormat(<br>
+ "aaaaaaaaaaaaaaaaaaaaaaaa(\n"<br>
+ " aaaaaaaaaaaaaaaaaaaaa(\n"<br>
+ " aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaa)),\n"<br>
+ " aaaaaaaaaaaaaaaa);",<br>
+ Style);<br>
+ verifyFormat(<br>
+ "aaaaaaaaaaaaaaaaaaaaaaaa(\n"<br>
+ " aaaaaaaaaaaaaaaaaaaaa(\n"<br>
+ " aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaa)) &&\n"<br>
+ " aaaaaaaaaaaaaaaa);",<br>
+ Style);<br>
}<br>
<br>
TEST_F(FormatTest, ParenthesesAndOperandAlignment) {<br>
<br>
<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>