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

[Mehdi AMINI via cfe-dev]

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