[clang-format] Fix AlignOperands when BreakBeforeBinaryOperators is set

[Typz]

Summary

Even when BreakBeforeBinaryOperators is set, AlignOperands kept
aligning the beginning of the line, even when it could align the
actual operands (e.g. after an assignment).

With this patch, the operands are actually aligned, and the operator
gets aligned with the equal sign:

int aaaaa = bbbbbb
          + cccccc;

This not happen in tests, to avoid 'breaking' the indentation:

if (aaaaa
    && bbbbb)
  return;

[Typz]

This patch fixes the behavior to match the name of the option, but maybe the original behavior was actually by design: should I instead add an option (e.g. make an enum out of a AlignOperands) instead?

[djasper]

The current behavior here is actually intended. If you'd like the other format, we probably need to add a style option. What style guide are you basing this on?

unittests/Format/FormatTest.cpp

3299

This looks very inconsistent to me.

[Typz]

we are using this style at our company, not sure if it is used elsewhere; I will check.

however, it seems to me that this behavior does not match the name of the option : AlignOperands does not align the operands anymore when BreakBeforeBinaryOperators is set...
so, for this patch to go forward, should I change AlignOperands into OperandAlignment enum, with 3 options? Something like

• OA_NotAligned, same as AlignOperands=false
• OA_AlignOperator, same the current AlignOperands=true
• OA_AlignOperands, same as AlignOperands=true when BreakBeforeBinaryOperators=false but my "new" mode when BreakBeforeBinaryOperators=true

unittests/Format/FormatTest.cpp

3299

not sure what you mean, I do not really understand how this expression was aligned before the patch...
it is not so much better in this case with the patch, but the '&&' is actually right-aligned with the '=' sign.

[Typz]

unittests/Format/FormatTest.cpp

3299

Seeing the test just before, I see (when breaking after operators) that the operands are actually right-aligned, e.g. all operators are on the same column.

So should it not be the same when breaking before the operator as well (independently from my patch, actually)?

bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                   + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                   + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
              == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                       * bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n"
                   + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n"
          && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                   * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
               > ccccccccccccccccccccccccccccccccccccccccc;

Not sure I like this right-alignment thing, but at least I start to understand how we get this output (and this may be another option to prefer left-alignment?)

[djasper]

When you say "this doesn't happen in tests", do you mean this never happens when there are parentheses around the expression?

unittests/Format/FormatTest.cpp

3299

The right alignment is not relevant. I think I just got "playful" when writing this test.

What's happening here is that we align the operators of subsequent lines to the previous operand. You are right that this is not intuitive wrt. the option's name, but it is the behavior that we intended and that we had seen in styles that use this.

Now, what we also do is add another ContinuationIndentWidth to highlight operator precedence. Basically think of this as replacing parentheses that you would put there instead:

int x = (aaaaa
         * bbbbb) // The "*" is intendet a space because of the paren.
        + ccccc;

int x = aaaaa
            * bbbbb // Instead we use ContinuationIndentWidth here.
        + ccccc;

What I mean about this being inconsistent is that now you align the highest-level operands because as you say that's what's expected from the option, but you still don't align other precedences, which seems wrong. If you really wanted to align all operands, that would look like:

bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
           + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
           + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
          == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
           * bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
           + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
          && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
           * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
           > ccccccccccccccccccccccccccccccccccccccccc;

But then, that's really a tough expression to understand. I mean, this is a fabricated example and possibly doesn't happen often in real life, but I am slightly worried about it and the inconsistency here.

[Typz]

In D32478#758258, @djasper wrote:

When you say "this doesn't happen in tests", do you mean this never happens when there are parentheses around the expression?

By 'test' I meant 'conditional construct' : it happens when there are parentheses around the expression, but it does not happen when these parentheses are the parentheses from a if (...)

[Typz]

unittests/Format/FormatTest.cpp

3299

So how should we proceed?

As I understand it, there are 2 separate issues here:

• The current behavior is actually the expected one, and should not be modified
• The indentation due to 'fake parenthesis' is not very explicit (even with the current implementation)

Changing AlignOperands into an OperandAlignment enum, with 3 options (OA_NotAligned, same as AlignOperands=false; OA_AlignOperator (or OA_Align), same the current AlignOperands=true; and OA_AlignOperands (or OA_StrictAlign), with my new behavior), would solve the first problem. Would it be acceptable?

I don't think this is related to the extra indentation issue, the problem is already present, and the existing behavior is not that consistent or clear... But I think the 'fake parenthesis' indentation could easily be changed, independently from my patch, to use a dedicated operatorPrecedenceIndentWith instead of ContinuationIndentWidth (or a boolean indentOperatorPrecedence) : setting it would allow to force all operators aligned, independenty from the other options (and in a separate patch?).

What do you think?

[Typz]

add new value to AlignOperands to support this mode.
fix some corner cases.

[djasper]

In D32478#759347, @Typz wrote:

In D32478#758258, @djasper wrote:

When you say "this doesn't happen in tests", do you mean this never happens when there are parentheses around the expression?

By 'test' I meant 'conditional construct' : it happens when there are parentheses around the expression, but it does not happen when these parentheses are the parentheses from a if (...)

Are you sure? From reading the code, it seems that this happens exactly after "=" and "return". What's the behavior for function calls?

function(aaaaaaa //
+ bbbbb);

Or for expressions with just parens?

int a = (aaaaaa //
+ bbbbbb);

What if doing this would violate the ContinuationIndentWidth?

T t = aaaaa //
&& bbbbb;

lib/Format/ContinuationIndenter.cpp

1031

Fix style.

1232

I am not yet convinced you need a new flag in ParenState here. I guess you need it because the operators can have varying length and so you cannot just change LastSpace here?

[Typz]

It indeed does not happens inside any parenthesis (it would actually make things completely unreadable if there are imbricated parenthesis), and may get indented less than the ContinuationIndentWidth.

[Typz]

lib/Format/ContinuationIndenter.cpp

1232

exactly. This is set when passing through the equal/return sign, but indent must be adjusted for each line individually based on the actual size of that line's leading operator.

[Typz]

fix style

[djasper]

In all honesty, I think this style isn't thought out well enough. It really is a special case for only "=" and "return" and even there, it has many cases where it simply doesn't make sense. And then you have cases like this:

bool = aaaaaa //
    == bbbb //
    && ccccc;

Where the syntactic structure is lost entirely.

On top of that it has runtime downsides for all clang-format users because ParenState gets larger and more costly compare. As such, I am against moving forward with this. Can you remind me again, which coding style suggests this format?

unittests/Format/FormatTest.cpp

3435

I think this is wrong and we should not indent like this.

[Typz]

In D32478#765537, @djasper wrote:

In all honesty, I think this style isn't thought out well enough. It really is a special case for only "=" and "return" and even there, it has many cases where it simply doesn't make sense. And then you have cases like this:

bool = aaaaaa //
    == bbbb //
    && ccccc;

Where the syntactic structure is lost entirely.

It is not lost, extra indent for 'virtual' parenthesis is still there:

bool a = aaaaaa   //
          == bbbb //
      && ccccc;

On top of that it has runtime downsides for all clang-format users because ParenState gets larger and more costly compare. As such, I am against moving forward with this. Can you remind me again, which coding style suggests this format?

This is just a single extra bit (and there are still less than 16 such bits), so it does change the size of ParenState. As for the compare cost, I think it is within reach of the compiler's optimization, but it may indeed have a slight impact.

[djasper]

In D32478#765548, @Typz wrote:

In D32478#765537, @djasper wrote:

In all honesty, I think this style isn't thought out well enough. It really is a special case for only "=" and "return" and even there, it has many cases where it simply doesn't make sense. And then you have cases like this:

bool = aaaaaa //
    == bbbb //
    && ccccc;

Where the syntactic structure is lost entirely.

It is not lost, extra indent for 'virtual' parenthesis is still there:

bool a = aaaaaa   //
          == bbbb //
      && ccccc;

Ah, right, I was thinking about something else (commas where we don't add extra indentation. Anyhow, I don't think what you are writing is what clang-format produces. How could it indent relative to the "&&" when placing the "=="? It doesn't know how far to unindent at that point, I think.

On top of that it has runtime downsides for all clang-format users because ParenState gets larger and more costly compare. As such, I am against moving forward with this. Can you remind me again, which coding style suggests this format?

This is just a single extra bit (and there are still less than 16 such bits), so it does change the size of ParenState. As for the compare cost, I think it is within reach of the compiler's optimization, but it may indeed have a slight impact.

[Typz]

I actually don't know how, but it still manages somehow : I rebuilt this exact patch to ensure I gave you the correct output.
And the same behavior can be seen in the test cases, where the operator with highest precedence is aligned with the equal sign.

[djasper]

In D32478#765583, @Typz wrote:

I actually don't know how, but it still manages somehow : I rebuilt this exact patch to ensure I gave you the correct output.
And the same behavior can be seen in the test cases, where the operator with highest precedence is aligned with the equal sign.

So, it's formatting like this?

bool a = aaaaaa   //
          == bbbb //
      && ccccc;

auto a = aaaaaa    //
           == bbbb //
       + ccccc;

While that's interesting and I'd like to figure out how it actually works, I also think it's really weird to indent the inner "==" differently based on the kind of operator around it. The existing way to format these operators is nice and consistent here with always adding a multiple of four spaces.

[Typz]

Nop, it's formatted like this:

bool a = aaaaaa   //
          == bbbb //
      && ccccc;

bool a = aaaaaa //
      == bbbb   //
             + ccccc;

The current way to format operators is not affected: the indentation is done as "usual", then they are unindented by the operator width to keep the alignment...

[djasper]

In D32478#765642, @Typz wrote:

Nop, it's formatted like this:

bool a = aaaaaa   //
          == bbbb //
      && ccccc;

bool a = aaaaaa //
      == bbbb   //
             + ccccc;

The current way to format operators is not affected: the indentation is done as "usual", then they are unindented by the operator width to keep the alignment...

Ah damn. Didn't think about the precedences. What I wanted was for the highest level to have a one char operator, e.g.

bool a = aaaaaa //
           << bbbb   //
       | ccccc;

In D32478#765548, @Typz wrote:

In D32478#765537, @djasper wrote:

In all honesty, I think this style isn't thought out well enough. It really is a special case for only "=" and "return" and even there, it has many cases where it simply doesn't make sense. And then you have cases like this:

bool = aaaaaa //
    == bbbb //
    && ccccc;

Where the syntactic structure is lost entirely.

It is not lost, extra indent for 'virtual' parenthesis is still there:

bool a = aaaaaa   //
          == bbbb //
      && ccccc;

On top of that it has runtime downsides for all clang-format users because ParenState gets larger and more costly compare. As such, I am against moving forward with this. Can you remind me again, which coding style suggests this format?

This is just a single extra bit (and there are still less than 16 such bits), so it does change the size of ParenState. As for the compare cost, I think it is within reach of the compiler's optimization, but it may indeed have a slight impact.

I would still be interested in a coding style that recommends this format.

[Typz]

Ah damn. Didn't think about the precedences. What I wanted was for the highest level to have a one char operator, e.g.

bool a = aaaaaa //
           << bbbb   //
       | ccccc;

Almost, but not quite:

bool a = aaaaaa   //
          << bbbb //
       | ccccc;

i.e. the identifiers is indented by 4 characters, then the operator is 'unindented.

I would still be interested in a coding style that recommends this format.

We are using this at our compagny, but this is neither public nor open source.
I am sure I saw this style somewhere else, but I cannot remember where...
(This is also the style recommended for webkit's when returning booleans : https://webkit.org/code-style-guidelines/#indentation-wrap-bool-op, but probably because the continuation indent is 4...
and I am not sure this guide in Boost's Spirit library counts either: http://www.boost.org/doc/libs/1_56_0/libs/spirit/doc/html/spirit/notes/style_guide.html )

[Typz]

This style is used in the Skia project.

[Typz]

Rebase & fix indentation when newline is inserted after return or equal.

[Typz]

ping?

[djasper]

I don't want to move forward with this patch. But adding Manuel as another reviewer to sanity-check.

include/clang/Format/Format.h

169

The name is not intuitive. I don't think this is any more or less strict than the other version.

unittests/Format/FormatTest.cpp

3398

Comment seems to belong to "+ b" so should be aligned to it.

[Typz]

include/clang/Format/Format.h

169

It is a bit stricter in the sense that it really aligns operands, not operator with first operand... But this is indeed not very intuitive.

Any suggestion?

[Typz]

Rename option to AlignAfterOperator

[Typz]

I renamed the option to AlignAfterOperator, is it acceptable now?
(I also thought of UnindentOperator, but I think it is better to keep the notion of alignment)

Note that this style is used in multiple open-source projects: Skia, parts of QtCreator code base (e.g. in multiple plugins: clang, cpptools, android...), the OpenEXR library...

[Typz]

ping?

[Typz]

ping?

[Typz]

ping?

[klimek]

In D32478#806757, @Typz wrote:

I renamed the option to AlignAfterOperator, is it acceptable now?
(I also thought of UnindentOperator, but I think it is better to keep the notion of alignment)

Note that this style is used in multiple open-source projects: Skia, parts of QtCreator code base (e.g. in multiple plugins: clang, cpptools, android...), the OpenEXR library...

Sorry for the long response time. I don't see this style rule expressed explicitly in the Skia or QtCreator style guides - is this something that just happens to be done sometimes in the code bases? I have problems understanding the rules from the discussion (as well as the code / test tbh), is there a really concise way to give me the core of the idea?

[Typz]

Sorry for the long response time. I don't see this style rule expressed explicitly in the Skia or QtCreator style guides - is this something that just happens to be done sometimes in the code bases?

This is present in code base. Those project's style guides are not precise enough, and do not document the behavior for this case.

I have problems understanding the rules from the discussion (as well as the code / test tbh), is there a really concise way to give me the core of the idea?

The case I am trying to address is to really keep the _operands_ aligned after an assignment or return, in case line is wrapped *before* the operator.

int a = b
      + c;
return a
     + b;

while the current behavior with Style.AlignOperands = true; BreakBeforeBinaryOperators = true is to align the wrapped operator with the previous line's operand:

int a = b
        + c;
return a
       + b;

In the discussion, it appeared that this behavior is not a error (with respect to the name), but an expected behavior for most coding rules: hence the introduction of a third AlignOperands mode ("AlignAfterOperator"), to handle this new case.

From there the code actually got a bit more complex to support various corner cases (e.g. operators with different number of characters, wrapperd first line, do not unindent more than the enclosing brace...)

[klimek]

In D32478#920275, @Typz wrote:

Sorry for the long response time. I don't see this style rule expressed explicitly in the Skia or QtCreator style guides - is this something that just happens to be done sometimes in the code bases?

This is present in code base. Those project's style guides are not precise enough, and do not document the behavior for this case.

I have problems understanding the rules from the discussion (as well as the code / test tbh), is there a really concise way to give me the core of the idea?

The case I am trying to address is to really keep the _operands_ aligned after an assignment or return, in case line is wrapped *before* the operator.

int a = b
      + c;
return a
     + b;

while the current behavior with Style.AlignOperands = true; BreakBeforeBinaryOperators = true is to align the wrapped operator with the previous line's operand:

int a = b
        + c;
return a
       + b;

In the discussion, it appeared that this behavior is not a error (with respect to the name), but an expected behavior for most coding rules: hence the introduction of a third AlignOperands mode ("AlignAfterOperator"), to handle this new case.

From there the code actually got a bit more complex to support various corner cases (e.g. operators with different number of characters, wrapperd first line, do not unindent more than the enclosing brace...)

Checking out skia and looking at wrapped '+', I see various different formats, and random sampling I've found none so far that would fit your proposed rule. Unless I'm missing something, I'd agree with Daniel; this is not a rule that's widely used, and I'd say reformatting a code base to the clang-formatted variant will not regress readability.

[Typz]

Unless I'm missing something, I'd agree with Daniel; this is not a rule that's widely used, and I'd say reformatting a code base to the clang-formatted variant will not regress readability.

Unfortunately coding rules are not just about readability, but also about consistency at entreprise scale, thus as a general rule we should not change the established rules in an organizatoin.
There is history in rules, we have code which already uses these rules, so for consistency we must stick to the old rules (even if we would not necessarily choose the same rules if we were to start from scratch).

[klimek]

In D32478#920345, @Typz wrote:

Unless I'm missing something, I'd agree with Daniel; this is not a rule that's widely used, and I'd say reformatting a code base to the clang-formatted variant will not regress readability.

Unfortunately coding rules are not just about readability, but also about consistency at entreprise scale, thus as a general rule we should not change the established rules in an organizatoin.
There is history in rules, we have code which already uses these rules, so for consistency we must stick to the old rules (even if we would not necessarily choose the same rules if we were to start from scratch).

My guess is (but I might be wrong): if your code base is large enough and you search your internal code base for how well these rules are obeyed, I'd expect there to be a large number of violations (given that there is no automation to detect or fix those violations). In the end, getting actual consistency will require effort - either changing all violations, or changing everything to a consistent state with automation.

[Typz]

Rebase

[Typz]

rebase

[Typz]

Rebase

[Typz]

Rebase on top of D50078

[MyDeveloperDay]

clang/include/clang/Format/Format.h

187 ↗

(On Diff #226393)

I think you are missing an entry in the operator== in Format.h

[Typz]

clang/include/clang/Format/Format.h

187 ↗

(On Diff #226393)

It is there already, since this is not a new field, but just changing the type of an existing field.

[MyDeveloperDay]

I've read back through the previous comments, and I'm slightly struggling to understand the reason for the objections. (other than the normal public style)

I'd tend to be wary of the "if its not in a public style guide, its not coming in" rule despite me understanding the rationale for that stance many people have non-public projects but still have millions of lines of code to support:

Many public projects have often already adopted a .clang-format file anyway and as such their style is defined by only what clang-format currently supports and hence it cannot by definition then define a style that clang-format keeps altering the code away from.

So I baulk at the idea that a rule that introduces a new style can't come in, My rule of thumb is don't mess up anyone's existing code, don't make others pay too much for your feature, help us look after this excellent tool by helping the project (bugs, reviews).

With that in mind, I've gone back to the original documentation for AlignOperands and BreakBeforeBinaryOperators, and I'm afraid I cannot see the logic in the current capabilities that align code nicely with BreakBeforeBinaryOperators turned off

but not nicely with BreakBeforeBinaryOperators turned on

If I understand correctly, this new setting (which will be off by default) will allow the following for those that choose it.

and it may be the OCD in me, but that re-alignment makes me feel happy, for this reason alone I'd give this a LGTM, as long as your willing to help us support this behaviour going forward.

That's my rationale for accepting, plus the authors 2.5 years of rebasing a feature, shows a dedication which I am assuming extends to continued support.

my 2c worth.

(images from https://zed0.co.uk/clang-format-configurator/) - 10.0.0+b452de0

clang/include/clang/Format/Format.h

187 ↗

(On Diff #226393)

sound good.

clang/unittests/Format/FormatTest.cpp

4147 ↗

(On Diff #226393)

Nit: I get nervous when we change tests, can we simply add a new duplicated line

docs/ClangFormatStyleOptions.rst

.. code-block:: c++
 
       #define A                                                                      \
         int aaaa;                                                                    \
         int b;                                                                       \
         int dddddddddd;
 
 
 
-**AlignOperands** (``bool``)
-  If ``true``, horizontally align operands of binary and ternary
-  expressions.
+**AlignOperands** (``OperandAlignmentStyle``)
+  Option to specify the style to use when aligning operands.
 
-  Specifically, this aligns operands of a single expression that needs to be
-  split over multiple lines, e.g.:
+  Possible values:
+
+  * ``OAS_DontAlign`` (in configuration: ``DontAlign``)
+    Do not align operands of binary and ternary expressions.
+    The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
+    the start of the line.
+
+  * ``OAS_Align`` (in configuration: ``Align``)
+    Horizontally align operands of binary and ternary expressions.
+
+    Specifically, this aligns operands of a single expression that needs
+    to be split over multiple lines, e.g.:
 
     .. code-block:: c++
 
       int aaa = bbbbbbbbbbbbbbb +
                 ccccccccccccccc;
 
+    When ``BreakBeforeBinaryOperators`` is set, the wrapped operator is
+    aligned with the operand on the first line.
+
+    .. code-block:: c++
+
+      int aaa = bbbbbbbbbbbbbbb
+                + ccccccccccccccc;
+
+  * ``OAS_AlignAfterOperator`` (in configuration: ``AlignAfterOperator``)
+    Horizontally align operands of binary and ternary expressions.
+
+    This is similar to ``AO_Align``, except when
+    ``BreakBeforeBinaryOperators`` is set, the operator is un-indented so
+    that the wrapped operand is aligned with the operand on the first line.
+
+    .. code-block:: c++
+
+      int aaa = bbbbbbbbbbbbbbb
+              + ccccccccccccccc;
+
+
+
 **AlignTrailingComments** (``bool``)
   If ``true``, aligns trailing comments.
 
   .. code-block:: c++
 
     true:                                   false:
     int a;     // My comment a      vs.     int a; // My comment a
     int b = 2; // comment  b                int b = 2; // comment about b

include/clang/Format/Format.h

enum EscapedNewlineAlignmentStyle {
     ///     int dddddddddd;
     /// \endcode
     ENAS_Right,
   };
 
   /// Options for aligning backslashes in escaped newlines.
   EscapedNewlineAlignmentStyle AlignEscapedNewlines;
 
-  /// If ``true``, horizontally align operands of binary and ternary
-  /// expressions.
+  /// Different styles for aligning operands.
+  enum OperandAlignmentStyle {
+    /// Do not align operands of binary and ternary expressions.
+    /// The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
+    /// the start of the line.
+    OAS_DontAlign,
+    /// Horizontally align operands of binary and ternary expressions.
     ///
-  /// Specifically, this aligns operands of a single expression that needs to be
-  /// split over multiple lines, e.g.:
+    /// Specifically, this aligns operands of a single expression that needs
+    /// to be split over multiple lines, e.g.:
     /// \code
     ///   int aaa = bbbbbbbbbbbbbbb +
     ///             ccccccccccccccc;
     /// \endcode
-  bool AlignOperands;
+    ///
+    /// When ``BreakBeforeBinaryOperators`` is set, the wrapped operator is
+    /// aligned with the operand on the first line.
+    /// \code
+    ///   int aaa = bbbbbbbbbbbbbbb
+    ///             + ccccccccccccccc;
+    /// \endcode
+    OAS_Align,
+    /// Horizontally align operands of binary and ternary expressions.
+    ///
+    /// This is similar to ``AO_Align``, except when
+    /// ``BreakBeforeBinaryOperators`` is set, the operator is un-indented so
+    /// that the wrapped operand is aligned with the operand on the first line.
+    /// \code
+    ///   int aaa = bbbbbbbbbbbbbbb
+    ///           + ccccccccccccccc;
+    /// \endcode
+    OAS_AlignAfterOperator,
+  };
+
+  /// Option to specify the style to use when aligning operands.
+  OperandAlignmentStyle AlignOperands;
 
   /// If ``true``, aligns trailing comments.
   /// \code
   ///   true:                                   false:
   ///   int a;     // My comment a      vs.     int a; // My comment a
   ///   int b = 2; // comment  b                int b = 2; // comment about b
   /// \endcode
   bool AlignTrailingComments;

lib/Format/ContinuationIndenter.h

private:
   /// Update 'State' according to the next token being one of "(<{[".
   void moveStatePastScopeOpener(LineState &State, bool Newline);
   /// Update 'State' according to the next token being one of ")>}]".
   void moveStatePastScopeCloser(LineState &State);
   /// Update 'State' with the next token opening a nested block.
   void moveStateToNewBlock(LineState &State);
 
   /// Reformats a raw string literal.
-  /// 
+  ///
   /// \returns An extra penalty induced by reformatting the token.
   unsigned reformatRawStringLiteral(const FormatToken &Current,
                                     LineState &State,
                                     const FormatStyle &RawStringStyle,
                                     bool DryRun);
 
   /// If the current token is at the end of the current line, handle
   /// the transition to the next line.
ParenState(const FormatToken *Tok, unsigned Indent, unsigned LastSpace,
              bool AvoidBinPacking, bool NoLineBreak)
       : Tok(Tok), Indent(Indent), LastSpace(LastSpace),
         NestedBlockIndent(Indent), BreakBeforeClosingBrace(false),
         AvoidBinPacking(AvoidBinPacking), BreakBeforeParameter(false),
         NoLineBreak(NoLineBreak), NoLineBreakInOperand(false),
         LastOperatorWrapped(true), ContainsLineBreak(false),
         ContainsUnwrappedBuilder(false), AlignColons(true),
         ObjCSelectorNameFound(false), HasMultipleNestedBlocks(false),
-        NestedBlockInlined(false), IsInsideObjCArrayLiteral(false) {}
+        NestedBlockInlined(false), IsInsideObjCArrayLiteral(false),
+        UnindentOperator(false) {}
 
   /// \brief The token opening this parenthesis level, or nullptr if this level
   /// is opened by fake parenthesis.
   ///
   /// Not considered for memoization as it will always have the same value at
   /// the same token.
   const FormatToken *Tok;
 
struct ParenState {
   /// The start of a nested block (e.g. lambda introducer in C++ or
   /// "function" in JavaScript) is not wrapped to a new line.
   bool NestedBlockInlined : 1;
 
   /// \c true if the current \c ParenState represents an Objective-C
   /// array literal.
   bool IsInsideObjCArrayLiteral : 1;
 
+  /// Indicates the indent should be reduced by the length of the
+  /// operator.
+  bool UnindentOperator : 1;
+
   bool operator<(const ParenState &Other) const {
     if (Indent != Other.Indent)
       return Indent < Other.Indent;
     if (LastSpace != Other.LastSpace)
       return LastSpace < Other.LastSpace;
     if (NestedBlockIndent != Other.NestedBlockIndent)
       return NestedBlockIndent < Other.NestedBlockIndent;
     if (FirstLessLess != Other.FirstLessLess)
bool operator<(const ParenState &Other) const {
     if (VariablePos != Other.VariablePos)
       return VariablePos < Other.VariablePos;
     if (ContainsLineBreak != Other.ContainsLineBreak)
       return ContainsLineBreak;
     if (ContainsUnwrappedBuilder != Other.ContainsUnwrappedBuilder)
       return ContainsUnwrappedBuilder;
     if (NestedBlockInlined != Other.NestedBlockInlined)
       return NestedBlockInlined;
+    if (UnindentOperator != Other.UnindentOperator)
+      return UnindentOperator;
     return false;
   }
 };
 
 /// The current state when indenting a unwrapped line.
 ///
 /// As the indenting tries different combinations this is copied by value.
 struct LineState {

lib/Format/ContinuationIndenter.cpp

bool BreakBeforeOperator =
         (P->is(TT_BinaryOperator) &&
          Style.BreakBeforeBinaryOperators != FormatStyle::BOS_None) ||
         (P->is(TT_ConditionalExpr) && Style.BreakBeforeTernaryOperators);
     // Don't do this if there are only two operands. In these cases, there is
     // always a nice vertical separation between them and the extra line break
     // does not help.
     bool HasTwoOperands =
         P->OperatorIndex == 0 && !P->NextOperator && !P->is(TT_ConditionalExpr);
-    if ((!BreakBeforeOperator && !(HasTwoOperands && Style.AlignOperands)) ||
+    if ((!BreakBeforeOperator &&
+         !(HasTwoOperands &&
+           Style.AlignOperands != FormatStyle::OAS_DontAlign)) ||
         (!State.Stack.back().LastOperatorWrapped && BreakBeforeOperator))
       State.Stack.back().NoLineBreakInOperand = true;
   }
 
   State.Column += Spaces;
   if (Current.isNot(tok::comment) && Previous.is(tok::l_paren) &&
       Previous.Previous &&
       (Previous.Previous->isOneOf(tok::kw_if, tok::kw_for) ||
unsigned ContinuationIndenter::getNewLineColumn(const LineState &State) {
   if (NextNonComment->isOneOf(TT_CtorInitializerColon, TT_InheritanceColon,
                               TT_InheritanceComma))
     return State.FirstIndent + Style.ConstructorInitializerIndentWidth;
   if (Previous.is(tok::r_paren) && !Current.isBinaryOperator() &&
       !Current.isOneOf(tok::colon, tok::comment))
     return ContinuationIndent;
   if (Current.is(TT_ProtoExtensionLSquare))
     return State.Stack.back().Indent;
+  if (Current.isBinaryOperator() && State.Stack.back().UnindentOperator)
+    return State.Stack.back().Indent - Current.Tok.getLength() -
+           Current.SpacesRequiredBefore;
+  if (Current.isOneOf(tok::comment, TT_BlockComment, TT_LineComment) &&
+      NextNonComment->isBinaryOperator() && State.Stack.back().UnindentOperator)
+    return State.Stack.back().Indent - NextNonComment->Tok.getLength() -
+           NextNonComment->SpacesRequiredBefore;
   if (State.Stack.back().Indent == State.FirstIndent && PreviousNonComment &&
       PreviousNonComment->isNot(tok::r_brace))
     // Ensure that we fall back to the continuation indent width instead of
     // just flushing continuations left.
     return State.Stack.back().Indent + Style.ContinuationIndentWidth;
   return State.Stack.back().Indent;
 }
 
void ContinuationIndenter::moveStatePastFakeLParens(LineState &State,
 
   // Don't add extra indentation for the first fake parenthesis after
   // 'return', assignments or opening <({[. The indentation for these cases
   // is special cased.
   bool SkipFirstExtraIndent =
       (Previous && (Previous->opensScope() ||
                     Previous->isOneOf(tok::semi, tok::kw_return) ||
                     (Previous->getPrecedence() == prec::Assignment &&
-                     Style.AlignOperands) ||
+                     Style.AlignOperands != FormatStyle::OAS_DontAlign) ||
                     Previous->is(TT_ObjCMethodExpr)));
   for (SmallVectorImpl<prec::Level>::const_reverse_iterator
            I = Current.FakeLParens.rbegin(),
            E = Current.FakeLParens.rend();
        I != E; ++I) {
     ParenState NewParenState = State.Stack.back();
     NewParenState.Tok = nullptr;
     NewParenState.ContainsLineBreak = false;
     NewParenState.LastOperatorWrapped = true;
+    NewParenState.UnindentOperator = false;
     NewParenState.NoLineBreak =
         NewParenState.NoLineBreak || State.Stack.back().NoLineBreakInOperand;
 
     // Don't propagate AvoidBinPacking into subexpressions of arg/param lists.
     if (*I > prec::Comma)
       NewParenState.AvoidBinPacking = false;
 
     // Indent from 'LastSpace' unless these are fake parentheses encapsulating
     // a builder type call after 'return' or, if the alignment after opening
     // brackets is disabled.
     if (!Current.isTrailingComment() &&
-        (Style.AlignOperands || *I < prec::Assignment) &&
+        (Style.AlignOperands != FormatStyle::OAS_DontAlign ||
+         *I < prec::Assignment) &&
         (!Previous || Previous->isNot(tok::kw_return) ||
          (Style.Language != FormatStyle::LK_Java && *I > 0)) &&
         (Style.AlignAfterOpenBracket != FormatStyle::BAS_DontAlign ||
-         *I != prec::Comma || Current.NestingLevel == 0))
+         *I != prec::Comma || Current.NestingLevel == 0)) {
       NewParenState.Indent =
           std::max(std::max(State.Column, NewParenState.Indent),
                    State.Stack.back().LastSpace);
+    }
+
+    // If BreakBeforeBinaryOperators is set, un-indent a bit to account for
+    // the operator and keep the operands aligned
+    if (Style.AlignOperands == FormatStyle::OAS_AlignAfterOperator && Previous &&
+        (Previous->getPrecedence() == prec::Assignment ||
+         Previous->is(tok::kw_return)) &&
+        !Newline)
+      NewParenState.UnindentOperator = true;
 
     // Do not indent relative to the fake parentheses inserted for "." or "->".
     // This is a special case to make the following to statements consistent:
     //   OuterFunction(InnerFunctionCall( // break
     //       ParameterToInnerFunction));
     //   OuterFunction(SomeObject.InnerFunctionCall( // break
     //       ParameterToInnerFunction));
     if (*I > prec::Unknown)

lib/Format/Format.cpp

static void enumeration(IO &IO,
     IO.enumCase(Value, "Right", FormatStyle::ENAS_Right);
 
     // For backward compatibility.
     IO.enumCase(Value, "true", FormatStyle::ENAS_Left);
     IO.enumCase(Value, "false", FormatStyle::ENAS_Right);
   }
 };
 
+template <> struct ScalarEnumerationTraits<FormatStyle::OperandAlignmentStyle> {
+  static void enumeration(IO &IO, FormatStyle::OperandAlignmentStyle &Value) {
+    IO.enumCase(Value, "DontAlign", FormatStyle::OAS_DontAlign);
+    IO.enumCase(Value, "Align", FormatStyle::OAS_Align);
+    IO.enumCase(Value, "AlignAfterOperator", FormatStyle::OAS_AlignAfterOperator);
+
+    // For backward compatibility.
+    IO.enumCase(Value, "true", FormatStyle::OAS_Align);
+    IO.enumCase(Value, "false", FormatStyle::OAS_DontAlign);
+  }
+};
+
 template <> struct ScalarEnumerationTraits<FormatStyle::PointerAlignmentStyle> {
   static void enumeration(IO &IO, FormatStyle::PointerAlignmentStyle &Value) {
     IO.enumCase(Value, "Middle", FormatStyle::PAS_Middle);
     IO.enumCase(Value, "Left", FormatStyle::PAS_Left);
     IO.enumCase(Value, "Right", FormatStyle::PAS_Right);
 
     // For backward compatibility.
     IO.enumCase(Value, "true", FormatStyle::PAS_Left);

 }
 
 FormatStyle getLLVMStyle() {
   FormatStyle LLVMStyle;
   LLVMStyle.Language = FormatStyle::LK_Cpp;
   LLVMStyle.AccessModifierOffset = -2;
   LLVMStyle.AlignEscapedNewlines = FormatStyle::ENAS_Right;
   LLVMStyle.AlignAfterOpenBracket = FormatStyle::BAS_Align;
-  LLVMStyle.AlignOperands = true;
+  LLVMStyle.AlignOperands = FormatStyle::OAS_Align;
   LLVMStyle.AlignTrailingComments = true;
   LLVMStyle.AlignConsecutiveAssignments = false;
   LLVMStyle.AlignConsecutiveDeclarations = false;
   LLVMStyle.AllowAllParametersOfDeclarationOnNextLine = true;
   LLVMStyle.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_All;
   LLVMStyle.AllowShortBlocksOnASingleLine = false;
   LLVMStyle.AllowShortCaseLabelsOnASingleLine = false;
   LLVMStyle.AllowShortIfStatementsOnASingleLine = false;
FormatStyle getGoogleStyle(FormatStyle::LanguageKind Language) {
   GoogleStyle.SpacesBeforeTrailingComments = 2;
   GoogleStyle.Standard = FormatStyle::LS_Auto;
 
   GoogleStyle.PenaltyReturnTypeOnItsOwnLine = 200;
   GoogleStyle.PenaltyBreakBeforeFirstCallParameter = 1;
 
   if (Language == FormatStyle::LK_Java) {
     GoogleStyle.AlignAfterOpenBracket = FormatStyle::BAS_DontAlign;
-    GoogleStyle.AlignOperands = false;
+    GoogleStyle.AlignOperands = FormatStyle::OAS_DontAlign;
     GoogleStyle.AlignTrailingComments = false;
     GoogleStyle.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_Empty;
     GoogleStyle.AllowShortIfStatementsOnASingleLine = false;
     GoogleStyle.AlwaysBreakBeforeMultilineStrings = false;
     GoogleStyle.BreakBeforeBinaryOperators = FormatStyle::BOS_NonAssignment;
     GoogleStyle.ColumnLimit = 100;
     GoogleStyle.SpaceAfterCStyleCast = true;
     GoogleStyle.SpacesBeforeTrailingComments = 1;
   } else if (Language == FormatStyle::LK_JavaScript) {
     GoogleStyle.AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
-    GoogleStyle.AlignOperands = false;
+    GoogleStyle.AlignOperands = FormatStyle::OAS_DontAlign;
     GoogleStyle.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_Empty;
     GoogleStyle.AlwaysBreakBeforeMultilineStrings = false;
     GoogleStyle.BreakBeforeTernaryOperators = false;
     // taze:, triple slash directives (`/// <...`), @tag followed by { for a lot
     // of JSDoc tags, and @see, which is commonly followed by overlong URLs.
     GoogleStyle.CommentPragmas =
         "(taze:|^/[ \t]*<|(@[A-Za-z_0-9-]+[ \\t]*{)|@see)";
     GoogleStyle.MaxEmptyLinesToKeep = 3;
FormatStyle getMozillaStyle() {
   MozillaStyle.SpaceAfterTemplateKeyword = false;
   return MozillaStyle;
 }
 
 FormatStyle getWebKitStyle() {
   FormatStyle Style = getLLVMStyle();
   Style.AccessModifierOffset = -4;
   Style.AlignAfterOpenBracket = FormatStyle::BAS_DontAlign;
-  Style.AlignOperands = false;
+  Style.AlignOperands = FormatStyle::OAS_DontAlign;
   Style.AlignTrailingComments = false;
   Style.BreakBeforeBinaryOperators = FormatStyle::BOS_All;
   Style.BreakBeforeBraces = FormatStyle::BS_WebKit;
   Style.BreakConstructorInitializers = FormatStyle::BCIS_BeforeComma;
   Style.Cpp11BracedListStyle = false;
   Style.ColumnLimit = 0;
   Style.FixNamespaceComments = false;
   Style.IndentWidth = 4;

unittests/Format/FormatTest.cpp

verifyFormat(
       "bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
       "                     + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
       "                     + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
       "                 == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
       "                            * bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n"
       "                        + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n"
       "             && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
       "                        * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
       "                    > ccccccccccccccccccccccccccccccccccccccccc;",
       Style);
   verifyFormat("if (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                "            * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                "        + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                "    == bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb) {\n}",
                Style);
   verifyFormat("if (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                "        + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                "              * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                "    == bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb) {\n}",
                Style);
   verifyFormat("if (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                "    == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                "               * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                "           + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb) {\n}",
                Style);
   verifyFormat("if () {\n"
                "} else if (aaaaa\n"
                "           && bbbbb // break\n"
                "                  > ccccc) {\n"
                "}",
                Style);
+  verifyFormat("return aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "       && bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;",
+               Style);
   verifyFormat("return (a)\n"
                "       // comment\n"
                "       + b;",
                Style);
   verifyFormat(
       "int aaaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
       "                 * bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n"
       "             + cc;",
verifyFormat(
       "    + sizeof(int8_t); // Segment Size (in bytes)");
 
   verifyFormat("return boost::fusion::at_c<0>(iiii).second\n"
                "       == boost::fusion::at_c<1>(iiii).second;",
                Style);
 
   Style.ColumnLimit = 60;
   verifyFormat("zzzzzzzzzz\n"
-               "    = bbbbbbbbbbbbbbbbb\n"
-               "      >> aaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaa);",
+               "    = bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n"
+               "      >> aaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaa);",
+               Style);
+}
+
+TEST_F(FormatTest, ExpressionIndentationStrictAlign) {
+  FormatStyle Style = getLLVMStyle();
+  Style.BreakBeforeBinaryOperators = FormatStyle::BOS_All;
+  Style.AlignOperands = FormatStyle::OAS_AlignAfterOperator;
+
+  verifyFormat("bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "                   + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "                   + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "              == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "                         * bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n"
+               "                     + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n"
+               "          && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "                     * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "                 > ccccccccccccccccccccccccccccccccccccccccc;",
+               Style);
+  verifyFormat("if (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "            * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "        + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "    == bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb) {\n}",
+               Style);
+  verifyFormat("if (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "        + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "              * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "    == bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb) {\n}",
+               Style);
+  verifyFormat("if (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "    == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "               * aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "           + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb) {\n}",
+               Style);
+  verifyFormat("if () {\n"
+               "} else if (aaaaa\n"
+               "           && bbbbb // break\n"
+               "                  > ccccc) {\n"
+               "}",
+               Style);
+  verifyFormat("return aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "    && bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;",
+               Style);
+  verifyFormat("return (a)\n"
+               "     // comment\n"
+               "     + b;",
+               Style);
+  verifyFormat(
+      "int aaaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+      "               * bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n"
+      "           + cc;",
+      Style);
+
+  verifyFormat("aaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
+               "    = aaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaaaaaaaaaa;",
+               Style);
+
+  verifyFormat("return boost::fusion::at_c<0>(iiii).second\n"
+               "    == boost::fusion::at_c<1>(iiii).second;",
+               Style);
+
+  Style.ColumnLimit = 60;
+  verifyFormat("zzzzzzzzzzzzz\n"
+               "    = bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n"
+               "   >> aaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaa);",
                Style);
+
+  // Forced by comments.
+  Style.ColumnLimit = 80;
+  verifyFormat(
+      "unsigned ContentSize\n"
+      "    = sizeof(int16_t) // DWARF ARange version number\n"
+      "    + sizeof(int32_t) // Offset of CU in the .debug_info section\n"
+      "    + sizeof(int8_t)  // Pointer Size (in bytes)\n"
+      "    + sizeof(int8_t); // Segment Size (in bytes)",
+      Style);
+
+  Style.BreakBeforeBinaryOperators = FormatStyle::BOS_NonAssignment;
+  verifyFormat(
+      "unsigned ContentSize =\n"
+      "    sizeof(int16_t)   // DWARF ARange version number\n"
+      "    + sizeof(int32_t) // Offset of CU in the .debug_info section\n"
+      "    + sizeof(int8_t)  // Pointer Size (in bytes)\n"
+      "    + sizeof(int8_t); // Segment Size (in bytes)",
+      Style);
+
+  Style.BreakBeforeBinaryOperators = FormatStyle::BOS_None;
+  verifyFormat(
+      "unsigned ContentSize =\n"
+      "    sizeof(int16_t)   // DWARF ARange version number\n"
+      "    + sizeof(int32_t) // Offset of CU in the .debug_info section\n"
+      "    + sizeof(int8_t)  // Pointer Size (in bytes)\n"
+      "    + sizeof(int8_t); // Segment Size (in bytes)",
+      Style);
 }
 
 TEST_F(FormatTest, EnforcedOperatorWraps) {
   // Here we'd like to wrap after the || operators, but a comment is forcing an
   // earlier wrap.
   verifyFormat("bool x = aaaaa //\n"
                "         || bbbbb\n"
                "         //\n"
                "         || cccc;");
 }
 
 TEST_F(FormatTest, NoOperandAlignment) {
   FormatStyle Style = getLLVMStyle();
-  Style.AlignOperands = false;
+  Style.AlignOperands = FormatStyle::OAS_DontAlign;
   verifyFormat("aaaaaaaaaaaaaa(aaaaaaaaaaaa,\n"
                "               aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +\n"
                "                   aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);",
                Style);
   Style.BreakBeforeBinaryOperators = FormatStyle::BOS_NonAssignment;
   verifyFormat("bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                "            + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"
                "            + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"

 }
 
 TEST_F(FormatTest, ParenthesesAndOperandAlignment) {
   FormatStyle Style = getLLVMStyleWithColumns(40);
   verifyFormat("int a = f(aaaaaaaaaaaaaaaaaaaaaa &&\n"
                "          bbbbbbbbbbbbbbbbbbbbbb);",
                Style);
   Style.AlignAfterOpenBracket = FormatStyle::BAS_Align;
-  Style.AlignOperands = false;
+  Style.AlignOperands = FormatStyle::OAS_DontAlign;
   verifyFormat("int a = f(aaaaaaaaaaaaaaaaaaaaaa &&\n"
                "          bbbbbbbbbbbbbbbbbbbbbb);",
                Style);
   Style.AlignAfterOpenBracket = FormatStyle::BAS_DontAlign;
-  Style.AlignOperands = true;
+  Style.AlignOperands = FormatStyle::OAS_Align;
   verifyFormat("int a = f(aaaaaaaaaaaaaaaaaaaaaa &&\n"
                "          bbbbbbbbbbbbbbbbbbbbbb);",
                Style);
   Style.AlignAfterOpenBracket = FormatStyle::BAS_DontAlign;
-  Style.AlignOperands = false;
+  Style.AlignOperands = FormatStyle::OAS_DontAlign;
   verifyFormat("int a = f(aaaaaaaaaaaaaaaaaaaaaa &&\n"
                "    bbbbbbbbbbbbbbbbbbbbbb);",
                Style);
 }
 
 TEST_F(FormatTest, BreaksConditionalExpressions) {
   verifyFormat(
       "aaaa(aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaa\n"

 #define CHECK_PARSE(TEXT, FIELD, VALUE)                                        \
   EXPECT_NE(VALUE, Style.FIELD);                                               \
   EXPECT_EQ(0, parseConfiguration(TEXT, &Style).value());                      \
   EXPECT_EQ(VALUE, Style.FIELD)
 
 TEST_F(FormatTest, ParsesConfigurationBools) {
   FormatStyle Style = {};
   Style.Language = FormatStyle::LK_Cpp;
-  CHECK_PARSE_BOOL(AlignOperands);
   CHECK_PARSE_BOOL(AlignTrailingComments);
   CHECK_PARSE_BOOL(AlignConsecutiveAssignments);
   CHECK_PARSE_BOOL(AlignConsecutiveDeclarations);
   CHECK_PARSE_BOOL(AllowAllParametersOfDeclarationOnNextLine);
   CHECK_PARSE_BOOL(AllowShortBlocksOnASingleLine);
   CHECK_PARSE_BOOL(AllowShortCaseLabelsOnASingleLine);
   CHECK_PARSE_BOOL(AllowShortIfStatementsOnASingleLine);
   CHECK_PARSE_BOOL(AllowShortLoopsOnASingleLine);
TEST_F(FormatTest, ParsesConfiguration) {
   CHECK_PARSE("AlignEscapedNewlines: Right", AlignEscapedNewlines,
               FormatStyle::ENAS_Right);
   // For backward compatibility:
   CHECK_PARSE("AlignEscapedNewlinesLeft: true", AlignEscapedNewlines,
               FormatStyle::ENAS_Left);
   CHECK_PARSE("AlignEscapedNewlinesLeft: false", AlignEscapedNewlines,
               FormatStyle::ENAS_Right);
 
+  Style.AlignOperands = FormatStyle::OAS_Align;
+  CHECK_PARSE("AlignOperands: DontAlign", AlignOperands,
+              FormatStyle::OAS_DontAlign);
+  CHECK_PARSE("AlignOperands: Align", AlignOperands, FormatStyle::OAS_Align);
+  CHECK_PARSE("AlignOperands: AlignAfterOperator", AlignOperands,
+              FormatStyle::OAS_AlignAfterOperator);
+  // For backward compatibility:
+  CHECK_PARSE("AlignOperands: false", AlignOperands,
+              FormatStyle::OAS_DontAlign);
+  CHECK_PARSE("AlignOperands: true", AlignOperands, FormatStyle::OAS_Align);
+
   Style.UseTab = FormatStyle::UT_ForIndentation;
   CHECK_PARSE("UseTab: Never", UseTab, FormatStyle::UT_Never);
   CHECK_PARSE("UseTab: ForIndentation", UseTab, FormatStyle::UT_ForIndentation);
   CHECK_PARSE("UseTab: Always", UseTab, FormatStyle::UT_Always);
   CHECK_PARSE("UseTab: ForContinuationAndIndentation", UseTab,
               FormatStyle::UT_ForContinuationAndIndentation);
   // For backward compatibility:
   CHECK_PARSE("UseTab: false", UseTab, FormatStyle::UT_Never);

unittests/Format/FormatTestJS.cpp

verifyFormat("var x = aaaaaaaaaa ?\n"
                "    ccc;",
                getGoogleJSStyleWithColumns(20));
 
   verifyFormat("var b = a.map((x) => x + 1);");
   verifyFormat("return ('aaa') in bbbb;");
   verifyFormat("var x = aaaaaaaaaaaaaaaaaaaaaaaaa() in\n"
                "    aaaa.aaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;");
   FormatStyle Style = getGoogleJSStyleWithColumns(80);
-  Style.AlignOperands = true;
+  Style.AlignOperands = FormatStyle::OAS_Align;
   verifyFormat("var x = aaaaaaaaaaaaaaaaaaaaaaaaa() in\n"
                "        aaaa.aaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;",
                Style);
   Style.BreakBeforeBinaryOperators = FormatStyle::BOS_All;
   verifyFormat("var x = aaaaaaaaaaaaaaaaaaaaaaaaa()\n"
                "            in aaaa.aaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;",
                Style);