<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 9, 2014 at 2:18 AM, Tobias Grosser <span dir="ltr"><<a href="mailto:tobias@grosser.es" target="_blank">tobias@grosser.es</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 09/07/2014 11:01, Chandler Carruth wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I significantly prefer the new formatting FWIW.<br>
<br>
I don't like continuations without indent at all. I'm willing to concede<br>
the necessity of them for functions, but for variables it feels quite bad<br>
to me.<br>
<br>
An example of where the old behavior was very confusing for me, let's take<br>
the following code:<br>
<br>
static llvm::cl::opt<whatever> MyLongOptionName(args, more_args, "yadda<br>
yadda");<br>
<br>
If we end up (due to the specific balance of string length above) breaking<br>
before "MyLongOptionName" we get no indent. But if we break after the "("<br>
we get 4 spaces of indent. This is even weirder if your variable doesn't<br>
use a "type name(arg, arg);" style of initialization, but instead is "type<br>
name = a + b;" as now 'name' would get no indent but 'a' as the start of<br>
the second line would get indent. I understand the C++ grammar rules which<br>
lead to that scenario, but find it really awkward when reading code.<br>
<br>
With the new logic, there is one rule for all indentation when breaking a<br>
variable declaration across multiple lines: 4 spaces of indent. There is<br>
also one rule for indentation when breaking after the return type of a<br>
function: no indent.<br>
</blockquote>
<br></div>
I can follow your points and also disliked clang-format inconsistently breaking lines in several cases.  So seeing work in this area is great.<br>
<br>
If just seemed the commit affects large portions of LLVM, actively try to establish a certain coding style and change existing clang-format behavior in many cases.<br>
<br>
For such kind of changes, I would prefer an addition to the LLVM coding style that explains the reasoning and that ensures that we do once and for all agree on a certain style. In this commit we should have the style discussion.</blockquote>
</div><br>I think this is way too heavy weight of a process ... =[ It seems to slow everything down.</div><div class="gmail_extra"><br>I filed the bug specifically complaining about clang-format's changes (such as the revisions you cite) and none have argued for clang-format's current behavior. I know bugs aren't great points of discussion, but unless a bunch of people show up on this thread saying that they strongly prefer the other formatting, why not just fix polly and move on? I want to use, dogfood, and provide feedback on the new behavior, and I can't if we just revert the change because we're still pondering deeply the really marginal style implications here.</div>
</div>