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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
