[PATCH] D69764: [clang-format] Add East/West Const fixer capability

Manuel Klimek via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Aug 9 11:00:07 PDT 2021


klimek added a comment.

In D69764#2934686 <https://reviews.llvm.org/D69764#2934686>, @aaron.ballman wrote:

> In D69764#2934612 <https://reviews.llvm.org/D69764#2934612>, @MyDeveloperDay wrote:
>
>>> I was referring to @rsmith and @aaron.ballman (to clarify), both are maintainers in 'clang', the former of which is the 'superset' maintainer of this format project based on its directory. While Aaron is a peer-maintainer to this project, his contributions are immense, and his points are too-well-reasoned and motivated to be dismissed.
>>
>> Just so we are clear I'm not dismissing anyone opinions, @arron.ballman and I have been going at this quite a bit both on and off list. I have huge respect for these people, (even if the defence of my review it might not seem so). I can't even think to emulate their contributions.
>>
>> Ideally I'd like their blessing, but alas I fear that might be beyond my capabilities, but if there are things like the RFC that could even go some way to potentially them seeing a way forward that is mutually beneficial so that the door is even open a jar for this then I'm happy to try.
>>
>> If ultimately the answer is "no" then I need to understand what can be done if anything, if that means a new tool then I'm ok with that as the compromise. Out right dismissal, I would be very sorry to see.
>
> Here are my thoughts put in one place.
>
> 0) I like the idea of being able to format qualifier location, and I think clang-format is the tool I would reach for to perform that work
> .33) I wish this was generalized to handle all qualifiers rather than just `const`. (This is not a blocking wish.)
> .66) I wish this used "left" and "right" rather than "east" and "west" for user-facing options and documentation. (This is Very Strong wish but I won't block the patch over it.)
>
> 1. In general, I do not like the idea of my code formatting tool having opinions about the input source's existing formatting (I think valid code should remain valid). This is the area of concern causing me to ask for an RFC because I'm operating under the impression that not breaking code is (generally) the status quo for clang-format.
> 2. If the community consensus is that formatting can break code (blanket permission, case by case basis, whatever), I'll definitely abide by that decision. I just want it to be an explicit decision from a wider audience than people who might be following this very long-running patch.
> 3. The proposed opt-in nature of the check is a blessing and a curse. It alleviates some of the danger (it's not dangerous by default, you have to manually say you want it). But it doesn't eliminate the danger (code can still be broken) and it does raise the question of how often people opt into this sort of thing and whether it's worth the maintenance costs. I don't think any of us can answer those "do people opt in" questions though, so that's not a concern I think we should hold anything up over unless someone has actual data on usage of opt-in features for clang-format. I think opt-in alleviates enough of the danger that it's a worthwhile approach for this patch (and likely may be a good idea for a policy on future changes of the same kind).
>
> tl;dr: if there's an RFC and the community says "breaking changes aren't that big of a deal to us", it tips me from "against" to "in favor" for this functionality.

Happy to go the RFC route if @MyDeveloperDay wants to do that.

FWIW, I don't understand the idea of the community being a democracy. It is not, and never was. Chris has designed an escalation process, when this was raised to him - I don't know whether this was ever made official or tested.
I also don't see this as a big change from clang-format's principles - C++ is (unfortunately) way too complex to not be able to introduce subtle bugs - the history of clang-format is full of them.

Note that I don't think the change will get consensus on an RFC, but not making the change will not get consensus, either - in that case, other than escalating to a clear higher decision power, or letting main contributors make the call, I don't know what to do.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69764/new/

https://reviews.llvm.org/D69764



More information about the cfe-commits mailing list