[clang-format]: no space before trailing comment

[igagis]

to reproduce

.clang-format

---
AlignAfterOpenBracket: BlockIndent
AlignArrayOfStructures: Right
BinPackArguments: 'false'
ColumnLimit: '120'
ContinuationIndentWidth: '1'
IndentWidth: '1'
Language: Cpp
SpacesBeforeTrailingComments: '1'
SpacesInLineCommentPrefix:
  Minimum: 1
  Maximum: -1
Standard: Latest
TabWidth: '1'
UseCRLF: 'false'
UseTab: ForContinuationAndIndentation

...

main.cpp:

type tree( //
	2,
	{ // comment
		tree(3, {78, 89, 96}),
		tree(4, {32, 64, 128}),
		tree(42, {98, 99, 100})
	}
);

expected result

formatting is not changed

actual result

type tree( //
	2,
	{// comment
		tree(3, {78, 89, 96}),
		tree(4, {32, 64, 128}),
		tree(42, {98, 99, 100})}
);

The space before // comment is removed

version

$ clang-format --version
Debian clang-format version 15.0.0-++20220513071846+693758b28295-1~exp1~20220513071937.249

[llvmbot]

@llvm/issue-subscribers-clang-format

[Eplankton]

same problem

[HazardyKnusperkeks]

So this was done on purpose: 5a61139
So how to fix it? If I remove that check and assignment, someone else will get it's code misformatted.
But if we replace the { and } with ty( and ) the space is kept (some newlines are lost), but that basically is against

Fundamentally, C++11 braced lists are formatted exactly like function calls would be formatted in their place.

We could add another option, but I think that will be a bit too hard to configure, opinions @mydeveloperday @owenca @djasper ?

[HazardyKnusperkeks]

type tree( //
	2,
	{ // comment
		tree(3, {78, 89, 96}),
		tree(4, {32, 64, 128}),
		tree(42, {98, 99, 100})
	}
);

To keep the closing brace on a separate line, just add a trailing comma for the 3rd tree:

type tree( //
 	2,
 	{ // comment
 		tree(3, {78, 89, 96}),
 		tree(4, {32, 64, 128}),
 		tree(42, {98, 99, 100}),
 	}
 );

You may want to look into the InsertTrailingCommas option.

[igagis]

To keep the closing brace on a separate line, just add a trailing comma for the 3rd tree:

thanks for info, but this looks like a workaround. C++ doesn't require the last comma and clang-format should handle this case, as I see it.

[HazardyKnusperkeks]

To keep the closing brace on a separate line, just add a trailing comma for the 3rd tree:

thanks for info, but this looks like a workaround. C++ doesn't require the last comma and clang-format should handle this case, as I see it.

It does handle it, just not the way you want it to. ;) Other people rely on this handling.

[owenca]

So this was done on purpose: 5a61139 So how to fix it? If I remove that check and assignment, someone else will get it's code misformatted. But if we replace the { and } with ty( and ) the space is kept (some newlines are lost), but that basically is against

Fundamentally, C++11 braced lists are formatted exactly like function calls would be formatted in their place.

We could add another option, but I think that will be a bit too hard to configure, opinions @mydeveloperday @owenca @djasper ?

IMO if the comment after the { or ( is actually meant for the first entry/argument below it, it should start on a new line instead:

$ cat test.cpp
void foo() {
  bar({
       // Comment 1
       "first entry",
       // Comment 2
       "second entry"});
  baz(
      // Comment 1
      "first argument",
      // Comment 2
      "second argument");
}

But clang-formant formats them differently:

$ clang-format test.cpp
void foo() {
  bar({// Comment 1
       "first entry",
       // Comment 2
       "second entry"});
  baz(
      // Comment 1
      "first argument",
      // Comment 2
      "second argument");
}

I don't think we can avoid regressions if we decide to fix it.

[igagis]

I don't think we can avoid regressions if we decide to fix it.

I already have an impression that clang-format is not a robust software, sadly, there's nothing better at the moment :(

[rymiel]

No matter how good or robust clang-format is, it unfortunately can't read your mind

[HazardyKnusperkeks]

I don't think we can avoid regressions if we decide to fix it.

I already have an impression that clang-format is not a robust software, sadly, there's nothing better at the moment :(

Yes we have some crashes, but most of them are fixed very fast, so I'd call clang-format robust.
Apart from that how does it play for you to insult the work some people did for free for you? I certainly hope the users of the code you write are a bit more well behaved.

IMO if the comment after the { or ( is actually meant for the first entry/argument below it, it should start on a new line instead:

$ cat test.cpp
void foo() {
  bar({
       // Comment 1
       "first entry",
       // Comment 2
       "second entry"});
  baz(
      // Comment 1
      "first argument",
      // Comment 2
      "second argument");
}

But clang-formant formats them differently:

$ clang-format test.cpp
void foo() {
  bar({// Comment 1
       "first entry",
       // Comment 2
       "second entry"});
  baz(
      // Comment 1
      "first argument",
      // Comment 2
      "second argument");
}

I don't think we can avoid regressions if we decide to fix it.

A constructor call is also a function call, or not? Then the given example should also break

type tree( //

into

type tree(
          //

right?

If there is no objection, I'll start trying to fix it for all cases.

[igagis]

Apart from that how does it play for you to insult the work some people did for free for you? I certainly hope the users of the code you write are a bit more well behaved.

I also produce opensource code and I had couple of times some not well behaved users, but they had no any argumentation to their complaints.
Sorry, I didn't mean to insult you, I just express my impression. I understand that people do the work for free, but come on, "we are not going to fix it because we are afraid to break something else" doesn't sound like an excuse in 2022, but instead it sounds like a fragile code with a lack of test coverage.

IMO if the comment after the { or ( is actually meant for the first entry/argument below it, it should start on a new line instead:

in my example, the comment meant to force clang-format to break the line, it is not a comment to any argument. I just gave a // comment word in the example in order to refer to the comment easier. In the use case it should have been just an empty comment // to break the line.
In my understanding there should never be a break before // comment inserted by clang-format, because single line comments are often given in the end of the line, for that exact line, not for the next line. And clang-format cannot guess what was the user intention in this case.

A constructor call is also a function call, or not?

A constructor call is a function call, in my opinion.