Phabricator URL: https://phabricator.services.mozilla.com/D98693

When I run clang-format locally, it insists on 3 spaces beween the #else and the following comment (which lines it up with the comment on the following #endif) in the test code. But reviewbot complains and wants 2 spaces after the #else. If I make that change, my local clang-format (which is from mozbuild, and should be up-to-date) will revert it.

Jed, how do you run clang-format?
If you are using the system clang-format, it might have different output as clang-format evolves.

(In reply to Sylvestre Ledru [:Sylvestre] from comment #1)

Jed, how do you run clang-format?
If you are using the system clang-format, it might have different output as clang-format evolves.

I'm running ./mach clang-format -p path/to/file. I already tried rebasing to the latest m-c and running ./mach bootstrap --no-system-changes to make sure I had the latest version (no difference), and I straced it to verify that it was running clang-format from ~/.mozbuild (it was).

So the logical conclusion is that the version in our infra is out of date?

So the logical conclusion is that the version in our infra is out of date?

Sounds unlikely, we would have this issue more often.

Unfortunately, we aren't showing the clang-version in the log :/
https://treeherder.mozilla.org/jobs?repo=try&revision=e0cedec4486fa2cc2fdca9e795a81fda64d79cf9&selectedTaskRun=MyOwLUX_Rz2LsOweD2B_TA.0

I will add it to identify what is going on.

On my system:
% ~/.mozbuild/clang-tools/clang-tidy/bin/clang-format --version
clang-format version 11.0.0

(which is the expected version)

I've noticed that we have two different versions of clang-format, with the same --version string. One of them, which from out-of-band discussions seems to be the intended one and has been patched to fix a bug with comments after preprocessor directives, is the one that ./mach clang-format is using. The other one, which (if I understand correctly) wasn't meant to be used, matches the behavior of the bot. These are, respectively, $good_format and $bad_format in this example:

$ file=security/sandbox/common/test/SandboxTestingChild.cpp
$ good_format=~/.mozbuild/clang-tools/clang-tidy/bin/clang-format
$ bad_format=~/.mozbuild/clang/bin/clang-format
$ $good_format --version
clang-format version 11.0.0
$ $bad_format --version
clang-format version 11.0.0
$ $good_format $file | diff $file -
$ $bad_format $file | diff $file -
87c87
< #else   // XP_UNIX
---
> #else  // XP_UNIX

According to the CI, reviewbot uses the right one:
[task 2020-12-05T08:45:03.314Z] /builds/worker/workspace/clang-tools/clang-tidy/bin/clang-format Version = clang-format version 11.0.0

https://firefoxci.taskcluster-artifacts.net/QFKibB1UTm-tOohNRh9yfA/0/public/logs/live_backing.log

https://hg.mozilla.org/mozilla-central/rev/dd272ee9da2f

Should this be leave-open?

(In reply to Sylvestre Ledru [:Sylvestre] from comment #7)

According to the CI, reviewbot uses the right one:
[task 2020-12-05T08:45:03.314Z] /builds/worker/workspace/clang-tools/clang-tidy/bin/clang-format Version = clang-format version 11.0.0

Both of them print version 11.0.0 — the difference is a patch we applied locally — so I don't think that tells us anything?

it is telling us that the CI uses the right one: "/builds/worker/workspace/clang-tools/clang-tidy/bin/clang-format"

Anyway, Andi, could you please have a look why/where the clang-format from clang toolchain is used? (instead of clang-tools's)
thanks!

This has been fixed with the latest version of clang-tidy. There is a problem with the way how the artifact was built.