gedare wrote: > > Covering all double parens in a single sub-option is not precise enough for > > code bases that may want to have `__attribute__(( x ))` but also allow `if > > ( ( x ) )`. > > We should not go overboard with supporting all kinds of options/suboptions > imaginable. I don't think we should support spaces between consecutive parens > in the first place, which was likely a bug. > Well, it seems to be far too late to go back and change the default behavior.
> We can't just disregard the long-standing > [policy](https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options) > on adding new options. If anyone thinks that policy is outdated, they should > go through the RFC process and get it updated. I have no problem with this policy. I think it is a good policy. I can advocate for my position. My patches relate to the style maintenance of a widely-used real-time operating system. The code is [self-hosted](https://git.rtems.org/rtems/) and [mirrored on GitHub](https://github.com/RTEMS/rtems) with a [documented style guide](https://docs.rtems.org/branches/master/eng/coding-formatting.html). In addition, I have been and will continue to be willing to provide bug fix and other maintenance support to clang-format based on the changes submitted to support these style needs. At the moment, I need to satisfy a particular style rule that requires me to add spaces inside of conditional and compound expressions. This support basically exists in `clang-format` but the compound expressions fall under the `SpacesInParensOption.Other` category. In order to control compound expressions separately from other uses of parens, it seems to be the easiest thing to explicitly define "everything else" and control the injection of spaces within them. Eventually, it results in a much more controlled and configurable way to manage whitespace. If this is not desired, I will need to step back to consider my options further, and probably have to take this up with the other maintainers of my code base to see what, if any, concessions we can make based on what is allowed with `clang-format`. I'm trying to get to a point where we are able to use `clang-format` on our code base with enforced CI actions. It is still a ways to go before I get there. https://github.com/llvm/llvm-project/pull/77522 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
