[LLVMdev] running clang format on the Mips target

Tobias Grosser tobias at grosser.es
Fri Dec 20 15:00:11 PST 2013


On 12/20/2013 11:18 PM, Rafael EspĂ­ndola wrote:
> On 20 December 2013 15:52, reed kotler <rkotler at mips.com> wrote:
>> We are considering running clang format on the whole Mips target.
>>
>> Is there any rule against this?
>
> I don't think there is a rule, but even simpler things like "remove
> all trailing spaces" were not common in the past
>
>> Is there any good argument against doing this even if there is no rule
>> against it?
>
> It think the argument was that it makes history harder to follow. A
> git blame lands you on the reformatting patch and you have to manually
> skip them.
>
> I don't personally consider that a strong argument and I think polly
> did just that (run clang-format on everything), so it might be OK
> these days.

Unfortunately for Polly it was not as clean as we started using 
clang-format early, so we had to format piece by piece the sections that 
clang-format could already handle.

However, we now have an automatic clang-format buildbot so formatting 
became (in some way) a 'solved problem'.

One benefit of fully formatted source code is that there is no need for 
any new patches to include 'formatting fixes', which previously 
sometimes obfuscated submitted patches and commits. In fact, patch 
reviews are now free of formatting discussions. If the patch passes
make polly-check-format, it is ready to be discussed. (If it does not,
make polly-update-format needs to be run). Also, having a single 
formatting commit to skip might arguably be easier, than to have a mixed 
history of formatting and patches.

One reason that may hold us back from formatting all LLVM code is the 
risk of clang-format changing its formatting behavior. The only thing 
worse than formatting all code is formatting all code twice. ;)

 From my experience with Polly, clang-format's formatting has been 
largely stable the last months. Changes in its formatting behavior have 
normally been fixed quickly. So it may make sense to format more code.
I would still be afraid of formatting all LLVM, but maybe a backend is
a reasonable sized chunk.

Maybe Manual and Daniel have some experience in formatting a larger set 
of files.

Cheers,
Tobias




More information about the llvm-dev mailing list