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

[David Blaikie via 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/cfe-dev/attachments/20210827/5932fbd3/attachment.html>