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

On Tue, Aug 10, 2021 at 8:24 AM Renato Golin via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Tue, 10 Aug 2021 at 15:55, Manuel Klimek via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I agree that that was probably not obvious or stated very clearly
>> anywhere - clang-format for years was basically developed by a small
team
>> without much interest in input by the rest of the world, for a very
>> specific use case.
>> At the time we did not do a great job at spreading our thoughts with
the
>> world, as a lot of discussions were in person.
>>
>
> I think there's more to that than what was created by the people who
> created it.
>
> After being used extensively by people around the world, clang-format has
> perhaps grown to something that the original team did not envision.
>
> However, as a public clang tool, and as part of the LLVM
"family", it's no
> longer "a tool used by the team that created it", and not even
"a tool used
> by LLVM developers". It is truly a public tool maintained by the LLVM
> community.
>
> As such, I think we shouldn't restrict the design goals to the original
> design, or to what a small sub-group uses it for. Clang-format is an
> official tool like other visible stuff and should have the same community
> oversight as everything else.
>
> There is a high demand for a formatting tool that can do so much more than
> the original design and people have been using it, albeit precariously, for
> that purpose already.
>
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.

> So I believe the original policy that "breaking changes are a
benefit" can
> still be valid in a number of places, but it does not (and should not) need
> to be the only valid case. Definitely not the default, either.
>
> I think we need to take a step back and ask users what they expect, rather
> than push forward a policy that people never really wanted but coped with
> it anyway because there's nothing better.
>
> FWIW, borrowing suggestions from others in this thread, I propose we
> change the policy to:
>  * Breaking changes off by default, override behaviour with configuration
> files
>  * All behaviour must be controlled by a configuration flag with options
> explicit on doc/config
>  * Make explicit some options are breaking (comment/naming)
>  * Backwards compatibility is pursued, but can be broken in case of clear
> bugs
>
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).

>
> An easy way to manage the configuration in this case is to have a dump
> function (`clang-format --dump --config foo.cfg`) that reads a config file
> and dumps all missing parameters and their current values.
>
> Inline comments would be nice but make configuration management hard, so
> there could be a webpage that describes all options and the URL is dumped
> on the config file.
>
> cheers,
> --renato
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210810/3e85d356/attachment.html>

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".

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/78a73673/attachment.html>