[PATCH] clang-format: Implement AlwaysBreakAfterDeclarationReturnType.

strager strager.nds at gmail.com
Fri Jun 12 11:43:17 PDT 2015


================
Comment at: include/clang/Format/Format.h:278-281
@@ -277,1 +277,6 @@
 
+  /// \brief If \c true, always break after function declaration return types.
+  ///
+  /// \see AlwaysBreakAfterDeclarationReturnType
+  bool AlwaysBreakAfterDeclarationReturnType;
+
----------------
djasper wrote:
> strager wrote:
> > djasper wrote:
> > > Hm.. I wonder whether we should really have two separate flags here or a single flag with an enum value, e.g. AlwaysBreakAfterReturnType with the values (No, DefinitionOnly, All).
> > > 
> > > Not sure we'll also need DeclarationOnly, but I don't think so.
> > That would break all `.clang-format` files with `AlwaysBreakAfterDefinitionReturnType` specified, yes?
> Well, the corresponding old strings in the configuration file can still set the right enum value. In that way, this should be fully backwards compatible.
So would there be two members in Style, or one? What happens when both are specified? Do any other flags behave this way?

================
Comment at: lib/Format/ContinuationIndenter.cpp:129-130
@@ -128,2 +128,4 @@
   if (Current.is(TT_FunctionDeclarationName) &&
-      !Style.AlwaysBreakAfterDefinitionReturnType && State.Column < 6)
+      !(Style.AlwaysBreakAfterDefinitionReturnType ||
+        Style.AlwaysBreakAfterDeclarationReturnType) &&
+      State.Column < 6)
----------------
djasper wrote:
> strager wrote:
> > djasper wrote:
> > > I find the parentheses confusing.
> > What's a better way to write this?
> I would just do:
> 
>   if (Current.is(TT_FunctionDeclarationName) && State.Column < 6 &&
>       !Style.AlwaysBreakAfterDefinitionReturnType &&
>       !Style.AlwaysBreakAfterDeclarationReturnType)
Looking at this a bit more, we should probably do the same thing we do in `TokenAnnotator::calculateFormattingInformation`. How should I factor out the `IsDefinition` calculation?

http://reviews.llvm.org/D10370

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the cfe-commits mailing list