LLDB REFORMATTING IN PROGRESS

As has been discussed over the past few weeks the reformatting of the LLDB code base will take place shortly, followed by validation before committing these changes. Please suspend all commit activity. Any intervening commits will be reverted until the all-clear is given.

Kate Stone k8stone@apple.com
 Xcode Low Level Tools

The storm of commit messages might be a subtle clue, but here it is officially: the reformatting is complete and I’ve verified that no tests regressed locally in our macOS suite. Please begin any validation process you’ve signed up for on another platform, and if changes are necessary go ahead and land them individually.

From the commit message:

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

find . ( -iname “.c" -or -iname ".cpp” -or -iname “.h" -or -iname ".mm” ) -exec clang-format -i {} +
find . -iname “*.py” -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.

Thanks for your collective support and assistance in preparing for this change.

Kate Stone k8stone@apple.com
 Xcode Low Level Tools

I think it goes without saying, but henceforth, no changes should be landed without first passing them through clang-format. Personally, I will be reverting any I see that don’t conform. But I can’t promise to catch all of them.

FreeBSD currently fails to build due to header reordering in
source/Host/freebsd/Host.cpp which I'll sort out shortly.

I'd like to request that we avoid any functional changes other than
those restoring builds to green, until we get the "all clear" from
everyone who's signed up to validate other platforms.

-Ed

Everything compiles on Windows now but all the tests are failing with ERROR. I’m looking into this now.

I think Windows is good.

I am still seeing errors when building windows unittests. I'll have a
change for fixing that soon. Apart from that everything else looks
good on our side. I'll send an all clear once the unit tests get green
on windows.

pl

+1.

I also like the idea of a clang-format presubmit hook from the other thread.

pl

Windows unit tests passing now. All clear.

Hi!

clang-formatting of my patch changed the style outside the patch (diff: https://reviews.llvm.org/D24331?vs=70653&id=70654). Am I doing something wrong?

In order to clang-format only the diff, you should use the “git clang-format” extension command. Search for git-clang-format (yes, that one has an extra dash), and there should be instructions inside

But what about SVN users? :slight_smile:
Okay, I know format can be applied for modified fragments only. But why did we leave some places unformatted? I thought “clang-format -i find include source tools -name '*.[cpp|h]'” ends with empty diff.

The clang format webpage <http://clang.llvm.org/docs/ClangFormat.html&gt;
recommends the following (I haven't tried it, but it sounds like it
should work):
svn diff --diff-cmd=diff -x -U0 | clang-format-diff.py -i

I also expected that running clang-format on the current tree would be
a no-op, but actually I get a lot of changes, mostly to do with moving
comments around. I can only assume this is due to not using the exact
same version of the tool.

pl

Just to add some experiences from 'polly.llvm.org'. We always use the
latest version version of clang-format, because we also earlier observed
larger differences in formatting between different clang-format
versions. To simplify this format-checking we added a
'polly-check-format' command to our build system. In recent releases
clang-format formatting only changed little, if at all.

Best,
Tobias