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.
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/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
