[llvm-bugs] [Bug 25329] New: AlignConsecutiveAssignments misbehaves for type parameters

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Oct 27 08:47:14 PDT 2015


https://llvm.org/bugs/show_bug.cgi?id=25329

            Bug ID: 25329
           Summary: AlignConsecutiveAssignments misbehaves for type
                    parameters
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Formatter
          Assignee: unassignedclangbugs at nondot.org
          Reporter: gonzalobg88 at gmail.com
                CC: djasper at google.com, klimek at google.com,
                    llvm-bugs at lists.llvm.org
    Classification: Unclassified

With the configuration in appendix [*] the following happens

struct very_long_type_name0 {};
struct very_long_type_name1 {};
struct very_long_type_name2 {};

template <typename T, typename A = very_long_type_name0, 
          typename B             = very_long_type_name1,
          typename C             = very_long_type_name2>
auto foo() {}

I think this is very weird.

It should either:

1. insert a new line and align the consecutive assignments: 

template <typename T, 
          typename A = very_long_type_name0, 
          typename B = very_long_type_name1,
          typename C = very_long_type_name2>
auto foo() {}

2. don't align the consecutive assignments at all:

template <typename T, typename A = very_long_type_name0, 
          typename B = very_long_type_name1, typename C = very_long_type_name2>
auto foo() {}

or

3. align only some of them (this one is probably the best given my config):

template <typename T, typename A = very_long_type_name0, 
          typename B = very_long_type_name1, 
          typename C = very_long_type_name2>
auto foo() {}


Appendix: .clang-format

BasedOnStyle: Google
AccessModifierOffset: -1
AlignAfterOpenBracket: true
AlignConsecutiveAssignments: true
AlignEscapedNewlinesLeft: true
AlignOperands: true
AlignTrailingComments: true
AllowAllParametersOfDeclarationOnNextLine: true
AllowShortBlocksOnASingleLine: true
AllowShortCaseLabelsOnASingleLine: true
AllowShortFunctionsOnASingleLine: All
AllowShortIfStatementsOnASingleLine: true
AllowShortLoopsOnASingleLine: true
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakBeforeMultilineStrings: false
AlwaysBreakTemplateDeclarations: false
BinPackArguments: true
BinPackParameters: true
BreakBeforeBinaryOperators: true
BreakBeforeBraces: Attach
BreakBeforeTernaryOperators: true
BreakConstructorInitializersBeforeComma: true
ColumnLimit: 80
ConstructorInitializerAllOnOneLineOrOnePerLine: true
ConstructorInitializerIndentWidth: 1
ContinuationIndentWidth: 1
Cpp11BracedListStyle: true
DerivePointerBinding: false
ExperimentalAutoDetectBinPacking: false
ForEachMacros: ['RANGES_FOR', 'BOOST_FOREACH']
IndentCaseLabels: true
IndentFunctionDeclarationAfterType: true
IndentWidth: 2
IndentWrappedFunctionNames: true
KeepEmptyLinesAtTheStartOfBlocks: false
Language: Cpp
MaxEmptyLinesToKeep: 1
NamespaceIndentation: None
PenaltyBreakBeforeFirstCallParameter: 10
PointerAlignment: Left
SpaceAfterCStyleCast: false
SpaceBeforeAssignmentOperators: true
SpaceBeforeParens: ControlStatements
SpaceInEmptyParentheses: false
SpacesBeforeTrailingComments: 2
SpacesInCStyleCastParentheses: false
SpacesInParentheses: false
SpacesInAngles:  false
SpacesInSquareBrackets: false
Standard: Cpp11
TabWidth: 2
UseTab: Never

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20151027/30dac621/attachment-0001.html>


More information about the llvm-bugs mailing list