[PATCH] D69764: [clang-format] Add East/West Const fixer capability

[Gašper Ažman via cfe-commits]

It would probably be better to make the config option names for passes that
may mutate whitespace be prefixed with MaybeIncorrect than fork the tool.
Scary options are better than forks.

On Wed, Jul 14, 2021 at 6:42 PM MyDeveloperDay via Phabricator <
reviews at reviews.llvm.org> wrote:

> MyDeveloperDay added a comment.
>
> I wanted to address your other points so we at least can be aligned as I
> respect your opinion.
>
> > I'm however even more wary of adding yet another tool that will be
> almost the same as clang-format.
>
> Also agreed, but I see no other way forward.
>
> > It could work if it were a drop-in replacement of clang-format, but that
> seems to be very much wishful thinking to me.
>
> This is exactly my suggestion. D105943: [clang-format++] Create a new
> variant of the clang-format tool to allow additional  code mutating
> behaviour such as East/West Const Fixer <https://reviews.llvm.org/D105943>
> will be a new clang-format for those that accept the fact it will modify,
> why those who can't just can't NOT turn the options on  in the first place,
> I'm not quite sure, but I'm trying to be inclusive of everyone and find a
> road to a solution which is good for those that want it and those that don't
>
> If we create a new tool, I recommend you, I and some of the other
> clang-format regulars also be the CODE_OWNERS so we can innovate without
> feeling stifled.
>
> > First, maintenance burden to verify that the two don't diverge somehow.
>
> My aim would be to move the grunt of the  ClangFormat.cpp into lib/Format,
> so both processes could share them, the main() would effective become
> calling the same submain() but with a "Yes please mutate all you like
> variable"
>
> > Secondly, the drop-in replacement wouldn't be possible without changing
> clang-format itself (e.g. to ignore style options that are for
> "clang-format++" only).
>
> No I wouldn't do this, the old clang-format would ignore mutating passes
> the new one wouldn't, the style options would remain for both so they can
> both share a common .clang-format file (lets remember I don't want to do it
> this way!)
>
> > Also, it might divide the users into clang-format camp and
> clang-format++ camp (which may or may not be a problem).
>
> Of course, and it would "Fragment the Community", but this is what happens
> when some want to innovate and others like it the way it is (we see this
> all the time from mailing lists to bug tracker), but it doesn't have to be
> this way, we could simply have one binary to rule them all and keep in the
> community that you and I spend a significant amount of our time giving back
> to.
>
> > Lastly, I do think that clang-format can be as reliable with this patch
> as it's now.
>
> Me too.
>
> > Also, I'd be a bit surprised if people used it in CI immediately after
> this feature has landed without verifying that it doesn't break anything on
> their codebase.
>
> No I use CI in an advisory capacity with the -n or (--dry-run) option just
> to highlight violations not change them)
>
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D69764/new/
>
> https://reviews.llvm.org/D69764
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20210714/337e7af0/attachment.html>