[clang-format] unexpected break after binOp '<<'

[s1Sharp]

the problem occurred while checking for the correctness of the break after binary operators. The output statement 'tok::lessless' is then break line every possible time, which is not expected with the BreakBeforeBinaryOperators: None

Fixes #59797
Fixes #44363

[s1Sharp]

I have no way to link the issues related to the PR issue. I don't know why, but add a link to issue to this comment #44363 .
So, I want to start a little discussion about the solution.

I'll start with the problem - when using the BreakBeforeBinaryOperators: None option, I expect that the code

std::cout << "hello " << "world!";

with binary output operation to stream via token "<<" (tok::lessless)
clang-format output is:

std::cout << "hello "
                     << "world!";

This was unexpected for me and unnecessary, as well as for other users who have already created issues.
The token '<<' is a binary operator that have link to the "BreakBeforeBinaryOperators" option.

1th solution is: Apply the break of the binary operator '<<' only if BreakBeforeBinaryOperators is [All | NonAssignment]. And not break if BreakBeforeBinaryOperators is None. This solution is very simple, but, in my opinion, violates the user api and the user's expectations of the clang-format program.

2th solution is: Add new option that allowing specific behaviour, such as "BreakAfterStreamOperator" or "BreakAfterLessLessOperator" with options [ Leave | NoFitLine | All ].

I am open to discussions

[owenca]

Please add unit tests in clang/unittests/Format/.

[owenca]

2th solution is: Add new option that allowing specific behaviour, such as "BreakAfterStreamOperator" or "BreakAfterLessLessOperator" with options [ Leave | NoFitLine | All ].

We need a comprehensive solution to cover the following:

• when to break
• before or after the operator
• indenting or aligning
• binpack or one per line
• whether to break after a newline (\n, endl, etc.)

[HazardyKnusperkeks]

What Owen says. And given that the modified lines were removed, maybe the issue(s) are also gone?

To the review unrelated, why didn't it get the @llvm/pr-subscribers-clang-format thing?

[s1Sharp]

yes, issue with breaking after << is gone. I want to get your point about functionality clang-format and implementing new option such as "BreakAfterStreamOperator". As i can see, @HazardyKnusperkeks you agree with "owenca" point?

May be i can do something with this feature

[HazardyKnusperkeks]

yes, issue with breaking after << is gone. I want to get your point about functionality clang-format and implementing new option such as "BreakAfterStreamOperator". As i can see, @HazardyKnusperkeks you agree with "owenca" point?

May be i can do something with this feature

You are welcome to try. I'd go with the name BreakAfterOperatorLessLess. You need:

• The definition in FormatStyle.h.
• The documentation. (Run clang/doc/tools/dump_format_style.py)
• The parsing.
• The default value for LLVMStyle which does not change any current behavior.
• Tests which show various combinations of the option, with comments, and long lines.
• Consider the interaction with BreakBeforeBinaryOperators.

You can of course start with documentation and/or tests to show how you think it will work, even if you did not try to implement it.

[kadircet]

@s1Sharp are there any conclusions here? our code also incidentally relied on having new lines between string literals, mostly for the sake of having a line break after string literals that end with \n.

what do people think about restoring the functionality to break after string literals that end with \n?
https://github.com/search?q=%2F%5C%5Cn%5C%22%5Cn%5Cs*%3C%3C%5C+%5C%22%2F+language%3AC%2B%2B+&type=code&ref=advsearch shows a lot of examples of such pattern, so i feel like having that without an option initially easy relatively easy and likely to preserve clang-format's behavior for a lot of existing code for the next release. afterwards we can discuss introducing more options again.

[kadircet]

sent out #76795 for implementation

[s1Sharp]

@s1Sharp are there any conclusions here? our code also incidentally relied on having new lines between string literals, mostly for the sake of having a line break after string literals that end with \n.

what do people think about restoring the functionality to break after string literals that end with \n? https://github.com/search?q=%2F%5C%5Cn%5C%22%5Cn%5Cs*%3C%3C%5C+%5C%22%2F+language%3AC%2B%2B+&type=code&ref=advsearch shows a lot of examples of such pattern, so i feel like having that without an option initially easy relatively easy and likely to preserve clang-format's behavior for a lot of existing code for the next release. afterwards we can discuss introducing more options again.

First, I want to show how this works with the current code.
As an example, here are a couple of output statements.

.clang-format:

Language: Cpp
BasedOnStyle: Google

IndentWidth: 4

ColumnLimit: 70

before clang-format:

  cout << "hello\n" << "World\n" << "HELLO" << "world" << "hello" << "World" << "HELLO" << "world" << "hello" << "World" << "HELLO" << "world";

  cout << "hello" << std::endl << "World" << "hello" << '\n' << "another hello" << "world";

  cout << "hello\n"
       << "World" << std::endl
       << "HELLO" << "world";

after clang-format:

    cout << "hello\n"
         << "World\n"
         << "HELLO" << "world" << "hello" << "World" << "HELLO"
         << "world" << "hello" << "World" << "HELLO" << "world";

    cout << "hello" << std::endl
         << "World" << "hello" << '\n'
         << "another hello" << "world";

    cout << "hello\n" << "World" << std::endl << "HELLO" << "world";

A bit unexpected results, right? Formatting applies to single-line expressions and breaks to another line after the \n and std::endl characters. And if the code has already been manually formatted (as in 3rd cout), then clang-format groups this code into a single-line expression.

I agree with your suggestion that to maintain compatibility with the old behavior of clang-format.

[mydeveloperday]

closed due to inactivity