owenca wrote:

> > If this were in the [GNU coding 
> > standards](https://www.gnu.org/prep/standards/standards.html#Formatting), I 
> > might agree to adding some special handling for GNU without adding a new 
> > option. Regardless, I'm inclined to oppose an option this niche.
> > @kgerlich you can make clang-format leave `_(` alone by using the 
> > [`OneLineFormatOffRegex`](https://clang.llvm.org/docs/ClangFormatStyleOptions.html#onelineformatoffregex)
> >  option? For example:
> > ```
> > OneLineFormatOffRegex: ^_$
> > ```
> 
> Hmm, but that would turn off formatting entirely for those lines? Ideally, we 
> would still want other aspects of formatting to work.

Yes, that's what that option is for.

> This exception to the "space before parenthesis" applies to pretty much all 
> GNU projects, so I don't think it's that niche. For instance:
> 
> * 
> [coreutils](https://github.com/coreutils/coreutils/blob/35795a8e354d13721b11496d0a96bf9c0d25d506/src/ln.c#L193-L198)
> * 
> [gcc](https://github.com/gcc-mirror/gcc/blob/7dd28f0a815cdaf52b6f8f6039cabfde256aacc1/gcc/libsarifreplay.cc#L745-L766)
> * 
> [bash](https://github.com/bminor/bash/blob/a8a1c2fac029404d3f42cd39f5a20f24b6e4fe4b/eval.c#L260-L265)

It's niche or too specific because it would only apply to a single underscore 
as the function name.

> If it really helps, we can try to get the rule into the GNU coding standards 
> (I was thinking on 
> [this](https://www.gnu.org/prep/standards/html_node/Internationalization.html)
>  page).

It should go in the Formatting section I linked above, and specifically the 
paragraph below:
```
We find it easier to read a program when it has spaces before the 
open-parentheses and after the commas.
Especially after the commas.
```

> So we have all the three requirements that you stated:
> 
> * be used in a project of significant size (have dozens of contributors).

This is met by default as GNU is one of the predefined styles clang-format 
supports.

> * have a publicly accessible style guide.

See above. After it's updated, we can discuss how to support the behavior. I 
still prefer making `OneLineFormatOffRegex: ^_$` the default for GNU to adding 
an exception to `SBPO_Always` like the following:
```diff
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -4503,8 +4503,15 @@ unsigned TokenAnnotator::splitPenalty(const 
AnnotatedLine &Line,
 }
 
 bool TokenAnnotator::spaceRequiredBeforeParens(const FormatToken &Right) const 
{
-  if (Style.SpaceBeforeParens == FormatStyle::SBPO_Always)
+  if (Style.SpaceBeforeParens == FormatStyle::SBPO_Always) {
+    if (Style.BasedOnStyle.equals_insensitive("gnu")) {
+      const auto *Left = Right.Previous;
+      assert(Left);
+      if (Left->TokenText == "_")
+        return false;
+    }
     return true;
+  }
   if (Right.is(TT_OverloadedOperatorLParen) &&
       Style.SpaceBeforeParensOptions.AfterOverloadedOperator) {
     return true;
```
@mydeveloperday can you also chime in?

https://github.com/llvm/llvm-project/pull/159925
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to