djasper added inline comments.
================
Comment at: docs/ClangFormatStyleOptions.rst:221-235
@@ -220,3 +220,17 @@
-**AlwaysBreakAfterDefinitionReturnType**
(``DefinitionReturnTypeBreakingStyle``)
+**AlwaysBreakAfterDeclarationReturnType** (``ReturnTypeBreakingStyle``)
+ The function declaration return type breaking style to use.
+
+ Possible values:
+
+ * ``DRTBS_None`` (in configuration: ``None``)
+ Break after return type automatically.
+ ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
+ * ``DRTBS_All`` (in configuration: ``All``)
+ Always break after the return type.
+ * ``DRTBS_TopLevel`` (in configuration: ``TopLevel``)
+ Always break after the return types of top level functions.
+
+
+**AlwaysBreakAfterDefinitionReturnType** (``ReturnTypeBreakingStyle``)
The function definition return type breaking style to use.
----------------
Same as I am arguing on some of your other patches. Fewer options are easier to
maintain and easier to discover.
================
Comment at: include/clang/Format/Format.h:133-136
@@ -128,6 +132,6 @@
/// \brief If \c true, always break before multiline string literals.
///
/// This flag is mean to make cases where there are multiple multiline
strings
/// in a file look more consistent. Thus, it will only take effect if
wrapping
/// the string at that point leads to it being indented
----------------
Only one member in style, but parsing the configuration file should be
backwards compatible. If both are present in the configuration file, the
non-deprecated one should win. There is a few examples of where the
configuration options are parsed for backwards compatibility, e.g.
DerivePointerBinding.
================
Comment at: lib/Format/ContinuationIndenter.cpp:129-132
@@ -128,5 +128,6 @@
if (Current.is(TT_FunctionDeclarationName) &&
Style.AlwaysBreakAfterDefinitionReturnType == FormatStyle::DRTBS_None &&
+ Style.AlwaysBreakAfterDeclarationReturnType == FormatStyle::DRTBS_None &&
State.Column < 6)
return false;
----------------
You mean just the "!Line.Last->isOneOf(tok::semi, tok::comment);"? You can put
this into a member function of AnnotatedLine maybe?
http://reviews.llvm.org/D10370
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
