[LLVMdev] running clang format on the Mips target

[Manuel Klimek]

FYI, our usual recommendation is to use clang-format only on changed code,
unless there's strong evidence that the cost of the initial reformatting is
basically zero (which usually means a team / community is pretty unanimous
about the decision).


On Thu, Jan 9, 2014 at 11:53 AM, Tobias Grosser <tobias at grosser.es> wrote:

> Manuel, Daniel,
>
> I forgot to CC you in this mail. The thread here may be interesting to
> you, also in the light of the last discussion we had.
>
> Tobias
>
>
> On 12/21/2013 12:00 AM, Tobias Grosser wrote:
>
>> 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.
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140109/123b7d5e/attachment.html>