Use the new option StatementMacros from clang-format-8

RESOLVED FIXED in Firefox 68

Status

enhancement
RESOLVED FIXED
4 months ago
3 months ago

People

(Reporter: sylvestre, Assigned: sylvestre)

Tracking

unspecified
mozilla68
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

Attachments

(2 attachments)

It helps clang-format-8 to know if they should be considered as function
https://reviews.llvm.org/D33440

StatementMacros: [MARKUPMAP, ASSERT_TRUE, ASSERT_FALSE, TEST, CHECK]

Pushed by sledru@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/55ed5f885d52
Use the new option StatementMacros from clang-format-8 r=andi
https://hg.mozilla.org/integration/autoland/rev/6f723cac81dd
Apply the change with the option StatementMacros from clang-format-8 r=andi
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

If you're reading this bug because you're now getting unknown key 'StatementMacros' error messages when you try to hg commit: you need to re-run ./mach bootstrap to get the latest clang-format.

YAML:28:19: error: unknown key 'StatementMacros'
StatementMacros: [MARKUPMAP, ASSERT_TRUE, ASSERT_FALSE, TEST, CHECK]
                  ^

I am not sure why the new version of clang-format isn't downloaded immediately :/
Andi, any idea why? Thanks

Flags: needinfo?(bpostelnicu)

Yes it's the same thing that we have with clang-tidy based analysis, we don't have a setup that detects that the artifact is newer than what we have locally in order to begin the update process.
This was one of the reasons why we've added clang-tidy package to bootstrap, but this is sub-optimal so I've opened bug 1542694 for this.

Flags: needinfo?(bpostelnicu)

I ran mach bootstrap, and ~/.mozbuild/clang/bin/clang-format --version is still giving me 7.0.1.

So does ~/.mozbuild/clang-tools/clang-tidy/bin/clang-format --version. (Why is there two and which one should I be using?)

I had to comment out the StatementMacros: ... line in .clang-format to allow my editor's clang-format integration to continue working for the time being.

Ok, I figured this out: I had run mach bootstrap in a different tree, which was not updated to the latest mozilla-central. I did not realize mach bootstrap looked at in-tree files to determine what versions to download (though in retrospect that makes sense).

I feel the need to add some clarifications here:

  • ~/.mozbuild/clang represents the artifact for the compiler
  • ~/.mozbuild/clang-tools/clang-tidy represents the artifact for clang based static analysis, like clang-tidy and for formatting, clang-format

The artifacts that we download, ex. clang-tidy and clang are tied up with the version of the tree that we are using, so in order to get the latest artifacts you need to be on he head of the mozilla-central.

(In reply to Andi-Bogdan Postelnicu [:andi] from comment #12)

The artifacts that we download, ex. clang-tidy and clang are tied up with the version of the tree that we are using, so in order to get the latest artifacts you need to be on he head of the mozilla-central.

Apologies for starting to veer off topic, but this makes me wonder: is it then possible to get into a situation where you'd like to do development simultaneously on e.g. a central tree and a beta tree, but you can't because they share the .mozbuild artifacts and they require different versions of them?

I am running into the same issue with editor integration since vim-clang-format seems to always look to the system clang-format (unlike clang-format.py which has g:clang_format_path) and Ubuntu seems to be stuck on clang-format 6.0.0.

You can update to clang-format 8 by using https://apt.llvm.org/ on Ubuntu but I recommend that you update vim-clang-format to use ~/.mozbuild/clang-tools/clang-tidy/bin/clang-format

Thanks! It turns out there is an option in vim-clang-format after all:

let g:clang_format#command = $HOME . '/.mozbuild/clang-tools/clang-tidy/bin/clang-format'

Regressions: 1544238
You need to log in before you can comment on or make changes to this bug.