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

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.

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210810/d114e4cb/attachment.html>

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, Aug 10, 2021 at 5:24 PM 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.
>
> 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
>
FWIW, this seems very reasonable to me.
(and it is also what I understood MyDeveloperDay's original proposal to be).

Cheers,

-- 
Mehdi


>
> 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/20210811/e1871c95/attachment.html>