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

On Fri, Aug 27, 2021 at 1:43 PM Aaron Ballman via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Thanks to everyone who participated in the discussion, and especially
> to MyDeveloperDay for getting this started. Now that discussion on
> this RFC seems to have died down, I think it's worth circling back to
> see if we have consensus to move forward. From reading the threads, I
> think Renato summarized the consensus position nicely:
>
I agree with the following items:

>  * 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)
>
I disagree with this one:

>  * 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).

> Unless there is strong opposition to this, then I'd say MyDeveloperDay
> has an answer to their RFC. Any disagreement?
>
> ~Aaron
>
> On Wed, Aug 11, 2021 at 4:37 AM Mehdi AMINI via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> >
> >
> >
> > 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
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> 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/20210827/053b0d04/attachment.html>

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

On Fri, Aug 27, 2021 at 10:04 AM Manuel Klimek <klimek at google.com>
wrote:
>
> On Fri, Aug 27, 2021 at 1:43 PM Aaron Ballman via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
>>
>> Thanks to everyone who participated in the discussion, and especially
>> to MyDeveloperDay for getting this started. Now that discussion on
>> this RFC seems to have died down, I think it's worth circling back
to
>> see if we have consensus to move forward. From reading the threads, I
>> think Renato summarized the consensus position nicely:
>
>
> I agree with the following items:
>
>>
>>  * 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)
>
>
> I disagree with this one:
>
>>
>>  * 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).
Thank you for the feedback! I'm personally fine dropping that last
bullet if it's contentious. I think consensus on the first three
bullets are what's necessary to unblock MyDeveloperDay's review.

~Aaron
>
>>
>> Unless there is strong opposition to this, then I'd say
MyDeveloperDay
>> has an answer to their RFC. Any disagreement?
>>
>> ~Aaron
>>
>> On Wed, Aug 11, 2021 at 4:37 AM Mehdi AMINI via cfe-dev
>> <cfe-dev at lists.llvm.org> wrote:
>> >
>> >
>> >
>> > 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
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

+1 to what Manuel's said here.

One slight change I'd suggest is changing the term "breaking
changes" to
"non-whitespace changes", perhaps? (they aren't necessarily
breaking
anything) At least I assume that's the intent, but I might be wrong in
which case I'd love to better understand what's being proposed.

On Fri, Aug 27, 2021 at 7:03 AM Manuel Klimek via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Fri, Aug 27, 2021 at 1:43 PM Aaron Ballman via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Thanks to everyone who participated in the discussion, and especially
>> to MyDeveloperDay for getting this started. Now that discussion on
>> this RFC seems to have died down, I think it's worth circling back
to
>> see if we have consensus to move forward. From reading the threads, I
>> think Renato summarized the consensus position nicely:
>>
>
> I agree with the following items:
>
>
>>  * 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)
>>
>
> I disagree with this one:
>
>
>>  * 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).
>
>
>> Unless there is strong opposition to this, then I'd say
MyDeveloperDay
>> has an answer to their RFC. Any disagreement?
>>
>> ~Aaron
>>
>> On Wed, Aug 11, 2021 at 4:37 AM Mehdi AMINI via cfe-dev
>> <cfe-dev at lists.llvm.org> wrote:
>> >
>> >
>> >
>> > 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
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> _______________________________________________
> 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/20210827/5932fbd3/attachment.html>