Output not deterministic when run with a multi-line comment on a single line

[llvmbot]

Bugzilla Link	37478
Version	unspecified
OS	MacOS X
Reporter	LLVM Bugzilla Contributor

Extended Description

Running clang-format on its own output results in a different output for
the following example. Is this expected behavior? The example has a
multi-line comment on a single line of a function body.

$ clang-format -version
clang-format version 7.0.0 (tags/google/stable/2018-01-11)

$ cat foo.c
void foo() {
/* THIS IS A COMMENT */
}

$ clang-format foo.c > foo2.c
$ cat foo2.c
void foo() { /* THIS IS A COMMENT */ }

$ clang-format foo2.c > foo3.c
$ cat foo3.c
void foo() { /* THIS IS A COMMENT */
}

Thank You,
Akhil Indurti

[llvmbot]

I have noticed the same non-deterministic behaviour around single-line comments.

I have found the minimal config file which reproduces the bug as I observe it:

$ cat .clang-format

Language: Cpp
BasedOnStyle: Mozilla
AlignTrailingComments: false
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakAfterReturnType: None
ReflowComments: false
...

and here is an example of the bug as reported above:

$ cat test.cpp

void main() {
function_call_with_really_long_name_aaaaaaaa(lots, of arguments_with_long_names, which, must_be_split_up, and_with); // a comment up here
// and another indented here.
}

$ clang-format test.cpp > format1.cpp
$ cat format1.cpp

void main()
{
function_call_with_really_long_name_aaaaaaaa(lots,
of arguments_with_long_names,
which,
must_be_split_up,
and_with); // a comment up here
// and another indented here.
}
$ clang-format format1.cpp > format2.cpp
$ cat format2.cpp

void main()
{
function_call_with_really_long_name_aaaaaaaa(lots,
of arguments_with_long_names,
which,
must_be_split_up,
and_with); // a comment up here
// and another indented here.
}
$ diff format1.cpp format2.cpp && echo 'two passes match' || echo 'two passes were different'
9c9
< // and another indented here.

// and another indented here.
two passes were different

We also saw a similar issue with whitespace inside comments, which is why we disabled ReflowComments (the first pass would reflow the comment but not add correct whitespace, which the second pass would fix. If you would like a minimal repro for that as well, I could make one.)

It would be useful to have a response about how this issue is being prioritised (if at all). We are trying to introduce this tool into our CI, and the non-determinism is a stumbling block (multiple passes means our builds will take longer.)

Thank you,
Joe Jordan

[owenca]

Works as expected in 20.1.7