> On Oct 22, 2019, at 2:53 PM, Damjan Marion via Lists.Fd.Io
> <dmarion=me....@lists.fd.io> wrote:
>
>
> Just tried to run clang-format-{6,7,8,9} on output generated by gcc with "-E
> -P" on the one file from VPP src tree.
>
> Result is not great: 6 and 7 are producing same result. 8 and 9 are producing
> different results each.
>
> I specially like this difference between 8 and 9:
>
> - __typeof__(((0))) _y = (((0)));
> + __typeof__ (((0))) _y = (((0)));
>
> Or this one:
>
> - ptr++ [0] = val;
> + ptr++[0] = val;
>
> In all cases "--style=GNU" is used with clang-format.
Yes, but using a "standard" style then has the same issues as using GNU indent,
the definition is left up to the tool of what that means, and can change from
version to version.
What I was getting at is that clang-format allows defining more precisely the
formatting you want. For example I use this in my .clang-format:
---
# chopps local
# AlignConsecutiveAssignements: true
# AlignConsecutiveDeclarations: false
AlignEscapedNewlines: Left
# From vpp
AlignEscapedNewlinesLeft: true
AlignTrailingComments: true
AllowAllParametersOfDeclarationOnNextLine: true
AlwaysBreakAfterDefinitionReturnType: true
AllowShortIfStatementsOnASingleLine: false
AllowShortLoopsOnASingleLine: false
AllowShortFunctionsOnASingleLine: false
AlwaysBreakBeforeMultilineStrings: false
BreakBeforeBinaryOperators: false
BreakBeforeTernaryOperators: true
BinPackParameters: true
BreakBeforeBraces: GNU
ColumnLimit: 79
IndentCaseLabels: false
MaxEmptyLinesToKeep: 1
PenaltyBreakBeforeFirstCallParameter: 19
PenaltyBreakComment: 60
PenaltyBreakString: 1000
PenaltyBreakFirstLessLess: 120
PenaltyExcessCharacter: 1000000
PenaltyReturnTypeOnItsOwnLine: 20
PointerBindsToType: false
SpaceBeforeAssignmentOperators: true
SpaceBeforeParens: Always
SpacesBeforeTrailingComments: 1
SpacesInParentheses: false
SpaceInEmptyParentheses: false
SpacesInCStyleCastParentheses: false
SpaceAfterControlStatementKeyword: true
Cpp11BracedListStyle: true
Standard: Cpp11
SortIncludes: false
IndentWidth: 2
TabWidth: 8
UseTab: Always
IndentFunctionDeclarationAfterType: false
ContinuationIndentWidth: 4
...
FWIW, I haven't actually tested whether this generates exactly the same as GNU
indent now that I think about it, but it does seem to do things consistently
and could be tweaked more if it isn't close enough to what VPP style should be.
Thanks,
Chris.
> GNU Indent at least have multi year gaps between releases :)
>
> --
> Damjan
>
>
>> On 22 Oct 2019, at 20:07, Christian Hopps <cho...@chopps.org> wrote:
>>
>> What about switching to clang-format which one can perhaps better configure
>> (and thus keep stable)?
>>
>> Locally, in my plugin source, I've been using this:
>>
>> "
>> /*
>> * fd.io coding-style-patch-verification: CLANG
>> "
>>
>> (i.e., CLANG instead of ON)
>>
>> and then I have a directory local .clang-format file which mimics the
>> outcome of GNU indent as used by fd.io/vpp (as opposed to the vpp
>> .clang-format which appears to be very different and only applied to c++?)
>>
>> Additionally, I have a couple emacs functions in a save-hook that auto
>> format the file on save (it does this for both "ON" or "CLANG" picking the
>> right tool to use so this works for source outside of my plugin source as
>> well -- mostly). This mimics what e.g., golang folks are used to and is
>> rather nice.
>>
>> I suspect given the ability to configure clang-format, it might be a more
>> stable choice going forward.
>>
>> FWIW last time I mentioned this there was some indication that clang-format
>> didn't produce deterministic results, but this has not been the case for me,
>> I've seen that more with indent than clang-format. My save-hooks run the
>> tool twice to catch non-determinism, and abort any re-format in this case,
>> showing me the failure diff in another emacs buffer. That being said, my
>> code may not be exercising the failure cases as much (e.g., long field name
>> combinations appearing in the far right columns seems to give indent
>> hiccups).
>>
>> Thanks,
>> Chris.
>>
>>> On Oct 22, 2019, at 1:09 PM, Damjan Marion via Lists.Fd.Io
>>> <dmarion=me....@lists.fd.io> wrote:
>>>
>>>
>>> Folks,
>>>
>>> Now we have 2nd release of ubuntu out which comes with new GNU indent which
>>> introduces lot of bug fixes.
>>> Unfortunately our repo is full of products of bugs which are fixed, so it
>>> results in big mess when new indent is used.
>>>
>>> Most of the time, it is about space after __attribute__ where one version
>>> thinks it should be, and another version thinks it should not.
>>>
>>> Up to the point where we come up with some solution, I would like to
>>> propose following change as workaround:
>>>
>>> https://gerrit.fd.io/r/c/vpp/+/22937
>>>
>>> Thoughts?
>>>
>>> —
>>> Damjan
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Links: You receive all messages sent to this group.
>>>
>>> View/Reply Online (#14272): https://lists.fd.io/g/vpp-dev/message/14272
>>> Mute This Topic: https://lists.fd.io/mt/36446352/1826170
>>> Group Owner: vpp-dev+ow...@lists.fd.io
>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [cho...@chopps.org]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#14278): https://lists.fd.io/g/vpp-dev/message/14278
> Mute This Topic: https://lists.fd.io/mt/36446352/1826170
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [cho...@chopps.org]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14280): https://lists.fd.io/g/vpp-dev/message/14280
Mute This Topic: https://lists.fd.io/mt/36446352/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
