Clang format config for Weston

Harish Krupo harish.krupo.kps at intel.com
Thu Mar 14 17:04:08 UTC 2019


Hi,

I dumped the llvm configuration from clang-format, edited it and pruned
all the unneeded configs (like configs for other langauges).
I have to agree with Simon. It is indeed impossible to be able to get
the requirements exactly right with clang. I managed to get almost all
the configs right but some of the style options either don't have a
config or the existing config options aren't sufficient. For example the
`AlignAfterOpenBracket: Align`
for some reason doesn't work correctly for function declarations. Some
corrections don't seem to have a control (at least I couldn't find one).
For example clang-format changed this:
static const EGLint gl_renderer_opaque_attribs[] = {
       EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
       EGL_RED_SIZE, 1,
       EGL_GREEN_SIZE, 1,
       EGL_BLUE_SIZE, 1,
       EGL_ALPHA_SIZE, 0,
       EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
       EGL_NONE
};

to

static const EGLint gl_renderer_opaque_attribs[] = { EGL_SURFACE_TYPE,
                                                    EGL_WINDOW_BIT,
                                                    EGL_RED_SIZE,
                                                    1,
                                                    EGL_GREEN_SIZE,
                                                    1,
                                                    EGL_BLUE_SIZE,
                                                    1,
                                                    EGL_ALPHA_SIZE,
                                                    0,
                                                    EGL_RENDERABLE_TYPE,
                                                    EGL_OPENGL_ES2_BIT,
                                                    EGL_NONE };

and I couldn't find a way of controlling it. For people who are interested
in experimenting, please find my config below. Other option would be to
use a .editorconfig/.dir-locals.el but I don't think they can be used
with the CI. If anyone has other ideas on implementing code checking
which can be enabled on the CI, please do suggest :)

Config:
----------------------------
AlignAfterOpenBracket: Align
AlignConsecutiveAssignments: false
AlignConsecutiveDeclarations: false
AlignEscapedNewlines: Right
AlignOperands:   true
AlignTrailingComments: true
AllowAllParametersOfDeclarationOnNextLine: false
AllowShortBlocksOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: false
AllowShortFunctionsOnASingleLine: None
AllowShortIfStatementsOnASingleLine: false
AllowShortLoopsOnASingleLine: false
AlwaysBreakAfterReturnType: TopLevel
AlwaysBreakBeforeMultilineStrings: false
BinPackArguments: true
BinPackParameters: true
BreakBeforeBinaryOperators: None
BreakBeforeBraces: Linux
BreakBeforeTernaryOperators: false
BreakStringLiterals: true
ColumnLimit:     80
ContinuationIndentWidth: 8
Cpp11BracedListStyle: false
DerivePointerAlignment: true
DisableFormat:   false
ExperimentalAutoDetectBinPacking: false
ForEachMacros: ['wl_list_for_each', 'wl_list_for_each_safe', 'wl_list_for_each_reverse']
IncludeBlocks:   Preserve
IncludeCategories:
  - Regex:           '^"(llvm|llvm-c|clang|clang-c)/'
    Priority:        2
  - Regex:           '^(<|"(gtest|gmock|isl|json)/)'
    Priority:        3
  - Regex:           '.*'
    Priority:        1
IncludeIsMainRegex: '(_test)?$'
IndentCaseLabels: false
IndentPPDirectives: None
IndentWidth:     8
IndentWrappedFunctionNames: false
KeepEmptyLinesAtTheStartOfBlocks: false
MacroBlockBegin: ''
MacroBlockEnd:   ''
MaxEmptyLinesToKeep: 1
#PenaltyBreakAssignment: 2
#PenaltyBreakBeforeFirstCallParameter: 19
#PenaltyBreakComment: 300
#PenaltyBreakFirstLessLess: 120
#PenaltyBreakString: 1000
#PenaltyBreakTemplateDeclaration: 10
#PenaltyExcessCharacter: 1000000
#PenaltyReturnTypeOnItsOwnLine: 60
PointerAlignment: Right
ReflowComments:  true
SortIncludes:    true
SpaceAfterCStyleCast: false
SpaceBeforeAssignmentOperators: true
SpaceBeforeParens: ControlStatements
SpaceInEmptyParentheses: false
SpacesBeforeTrailingComments: 1
SpacesInContainerLiterals: true
SpacesInParentheses: false
SpacesInCStyleCastParentheses: false
SpacesInSquareBrackets: false
TabWidth: 8
UseTab: Always

Thank you
Regards
Harish Krupo

Harish Krupo <harish.krupo.kps at intel.com> writes:

> Pekka Paalanen <ppaalanen at gmail.com> writes:
>
>> On Thu, 14 Mar 2019 18:11:47 +0530
>> Harish Krupo <harish.krupo.kps at intel.com> wrote:
>>
>>> Pekka Paalanen <ppaalanen at gmail.com> writes:
>>
>>> > FYI, one thing I would never want to see in a patch is adding
>>> > '/* clang-format off */' kind of directives into code.
>>> >  
>>> 
>>> /* clang-format off */ directive is supposed to be used sparingly. If
>>> the whole code is commented out that way then I believe the reviewer
>>> should point that out. We could also add a check in the CI to
>>> ensure that the /* clang-format off */ and /* clang-format on */ pair
>>> don't span more than a few lines at a time.
>>
>> Hi Harish,
>>
>> no, I really mean they should never be used at all. If they are
>> actually necessary even once, then we did something wrong: we made it
>> an error in CI instead of only a warning, the format checker was was a
>> bad choice, or the format definition is off.
>>
>> If the directive is only needed sparingly, then it is not needed at
>> all, because reviewers can just say the checker in CI is wrong and merge
>> the patch with style warnings. If that becomes a hindrance, then it's
>> not "sparingly" anymore.
>
> Makes sense.
> I will create a config with all the necessary options for
> clang-format and probably we can then discuss if they make sense.
>
> Thank you
> Regards
> Harish Krupo
>
>>
>>
>> Thanks,
>> pq
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



More information about the wayland-devel mailing list