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

[David Blaikie via llvm-dev]

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>