[llvm-bugs] [Bug 42157] New: Clang-format of Additions and Subtractions Uses an Opaque Logic and is Confusing

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=42157

            Bug ID: 42157
           Summary: Clang-format of Additions and Subtractions Uses an
                    Opaque Logic and is Confusing
           Product: clang
           Version: 8.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Formatter
          Assignee: unassignedclangbugs at nondot.org
          Reporter: matthias.schaefer at versasec.com
                CC: djasper at google.com, klimek at google.com,
                    llvm-bugs at lists.llvm.org

.clang-format file:
Language: Cpp

After running clang-format the code is formatted as follows:
void Foo()
{
  var = (something) + 1;
  var = (something)-1;
  var = ((something)-1);
  (something) - 1;
  ((something)-1);
  var = (int)+1;
}

This formatting looks very inconsequent for several reasons:
- There are both plus and minus unary and binary operators, so the formatting
should not depend on the operator sign (compare statements 1 and 2).
- It seems that the formatting depends on whether the result of the operation
is assigned to a variable or not (compare statements 2 and 4).
- It seems that the previous bullet does not always apply (as the formatting in
statements 3 and 5 are identical).
- It seems that the formatting depends on the words written inside the
parentheses (compare statements 1 and 6).

I understand that it is difficult to decide for adding or for removing the
spaces as clang-format does not know if "something" is a type or an expression,
so it cannot deduce if the operation is binary or unary, but the logic above is
really confusing.

The easiest way to solve the inconsequences given above is to not touch
ambiguous code like this. Another solution is to use a heuristic which is
independent of the operator sign, of the usage of the result and of the words
written inside the parentheses. My suggestion is to look at the character after
the operator. If this character is a white space, you can assume the operator
is binary, otherwise you can assume the operator is unary. If the operator is
unary, the white space before the operator should be adjusted according to
SpaceAfterCStyleCast setting. This heuristic depends on the assumption that
binary operations are/shall always be formatted with white space around the
operator and that no other formatting option adds or removes the white space
after the operator as a whole.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190606/7d75b77c/attachment-0001.html>