[cfe-dev] [llvm-dev] [RFC] Adding support for clang-format making further code modifying changes

[MyDeveloper Day via cfe-dev]

Really thank you to everyone for the comments,on the RFC I thought I'd try
to keep quiet on the RFC so as not to appear overly pressing my agenda, I'm
super glad that we have got to a nice consensus, thank you to those that
summarized it.

We'll definitely take care, and we can introduce something into the
documentation at some point to highlight the existing breaking changes
(sort includes, namespace commenter etc...) and use this going forward.

On the point of "Version to Version" breaking, there doesn't feel like
something that can be solved easily other than us simply not touching the
code and not fixing bugs. We get a relatively good stream of people
logging issues in the bug tracker, and frankly we don't have enough people
working through them. (I personally can't keep up so I tend cherry pick!
depending on my availability.)

For the clang-format team the way to try and minimise the changes between
versions is IMHO to be quite strict about NOT changing any existing tests,
and I to push back on reviews that do unless there is good
reason. (i.e. the test was previously wrong)

 But I  still causing changes version to version mainly because we are
fixing bugs rather than adding new features. Recent improvement to make
clang-format handle K&R code better, means we now identify functions
better,
The consequence of which is in the large code base that I manage this
identified 100s of cases where "BreakAfterReturn" was incorrectly
formated previously. Also recent changes to AfterEnum to make it more
correct in enum detection
will likely find lots of places where enum was/n't breaking correctly.

In my view this issue is tangential to what we want to do with being able
to modify the token stream, which we'd hope to keep completely seperate and
not have any impact if turned off.

Some asked what was being proposed, and the review I was working on is for
clang-format ensuring consistent "Left/Right" const/volatile placement. (
https://reviews.llvm.org/D69764) Running this on LLVM shows a couple of
places where even we are not consistent, please note this is still WIP.

MyDeveloperDay


On Fri, Aug 27, 2021 at 7:33 PM Manuel Klimek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Fri, Aug 27, 2021 at 4:08 PM Renato Golin <rengolin at gmail.com> wrote:
>
>> On Fri, 27 Aug 2021 at 15:03, Manuel Klimek <klimek at google.com> wrote:
>>
>>>  * Backwards compatibility is pursued, but can be broken in case of
>>>> clear bugs
>>>>
>>>
>>> Which I think is also tangential to the current RFC, and IMO should be
>>> treated in a separate discussion if necessary (this is a fundamental
>>> problem with how clang-format is designed).
>>>
>>
>> Is this a fundamental problem with the code structure and maintainability
>> or with the mindset of the main developers?
>>
>
> It's the algorithm - clang-format is a numerical optimizer of "beauty" -
> any small changes can lead to the numerical outputs changing slightly,
> which then leads to slight diffs in how code is formatted where two options
> were previously considered very "similarly beautiful". It's not happening
> super often, but it does happen.
>
> I agree that we shouldn't introduce changes to formatting without good
> reasons, but we can't restrict changes only to bug fixes - new features can
> introduce changes, too.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210827/f97bb14f/attachment-0001.html>