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

[David Blaikie via llvm-dev]

On Tue, Aug 10, 2021 at 11:22 AM Renato Golin <rengolin at gmail.com> wrote:

> On Tue, 10 Aug 2021 at 17:43, David Blaikie <dblaikie at gmail.com> wrote:
>
>> Mixed feelings - we don't necessarily have to let users dictate the
>> feature set, if they aren't contributing to it. Like users using
>> -Weverything, that is ill advised and we are/should be more than happy to
>> break them at any turn. We do get to make choices about what uses we are
>> developing the tools for.
>>
>
> Ah, that's not what I meant. I agree with you.
>
> I meant there is a lot of potential for things that we (LLVM developers)
> are saying we want (in this thread) and we should pursue it without having
> to be bound by the "original design".
>

Fair - though I think it's insightful to know where things started/what the
goals were (& some of those are still relevant, since that original use
case is still a major use case), though it sounds like the direction we're
discussing is pretty compatible with that original vision - Google style
can continue to opt in to things consistent with that original vision of
"more than whitespace changes when they're worth it" while keeping them off
by default for unconfigured clang-format to make it safer-by-default. (LLVM
will probably opt into some too, I imagine - like brace addition/removal,
etc) Given both Google and LLVM are specific styles anyway, opting them
into some of these more-than-whitespace features while having them
otherwise off by default seems quite fine to me.

I think that's more-or-less what MyDeveloperDay has been saying? I think
>> that sounds reasonable to me (we could potentially rename the existing
>> features that do change more than whitespace, like include sorting - to
>> match the naming convention of "this changes the token sequence/can have an
>> effect on how/whether code compiles" - while keeping it on by default for
>> backwards compatibility).
>>
>
> It is, intentionally so. I didn't mean to hijack the thread, just validate
> the original point.
>
> Like the miscommunication you pointed above, this was a reply to a
> specific point to stick to the original design for the sake of "this is
> what we wanted back then", which I don't think it's a good policy.
>
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210810/03a83778/attachment.html>