[cfe-dev] Question about clang-format
Beren Minor via cfe-dev
cfe-dev at lists.llvm.org
Thu Nov 26 13:30:03 PST 2015
I've updated http://reviews.llvm.org/D14325 with a fix for the parameter
declaration alignment issue.
--
Beren Minor
On Sun, Nov 22, 2015 at 11:43 PM, Graham St Jack via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Thanks for the reply - my response is late too because I have been on
> leave.
>
> On 19/11/15 05:21, via cfe-dev wrote:
>
>>
>> Message: 4
>> Date: Wed, 18 Nov 2015 19:53:34 +0100
>> From: Beren Minor via cfe-dev <cfe-dev at lists.llvm.org>
>> To: Daniel Jasper <djasper at google.com>
>> Cc: cfe-dev at lists.llvm.org, graham.stjack at quantum.com
>> Subject: Re: [cfe-dev] Question about clang-format
>> Message-ID:
>> <CAONPvZxsy4=S+Yaa3vxL6Gy983-BsTag4G2UBga9hc8c3CW8=
>> Q at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Sorry for the late answer, the mail was lost in my inbox.
>>
>> You're totally right about the pointer and reference attachment rules, but
>> currently the alignment code doesn't really handle it. I don't think it
>> would be very hard to implement, but I am wondering what the expected
>> alignment would be in the case of nested pointer / cv qualifiers. I
>> personally find such cases troublesome, and that is why I usually attach
>> the pointers and qualifiers to the type and not to the variable.
>>
>> For example, where should the spaces be inserted in the following case:
>>
>> const char* const* v1;
>> float const* v2;
>> SomeVeryLongType const& v3;
>>
> These use cases don't come up in our code base (we only care about the
> constness of what is pointed/referred to, so the question doesn't arise -
> but I see the problem.
>
> For us, what happens with cases like this are more compelling:
>
> const char *v1, *v2, v3;
>
> Hence our interest in associating the pointer/reference with the variable
> rather than the type - although I do admit that we frown on declaring more
> than one variable per line.
>
>
>> Regarding the function parameter misalignment, this is certainly a bug and
>> you can file a bugreport about it if you like. I will try to reproduce and
>> fix it anyway.
>>
>
> I will leave it in your court, thanks. This is the one that is the real
> blocker.
>
> Thanks,
>> --
>> Beren Minor
>>
>> On Fri, Nov 13, 2015 at 9:52 AM, Daniel Jasper <djasper at google.com>
>> wrote:
>>
>> Adding Beren, who has done the development here.
>>>
>>>
>>> On Fri, Nov 13, 2015 at 12:01 AM, Graham St Jack via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>>
>>> Hi all,
>>>>
>>>> I am looking at using clang-format, and like everyone else with a
>>>> pre-existing quirky style, there are some things that clang-format
>>>> doesn't
>>>> seem to handle for me.
>>>>
>>>> Most of the issues are minor - we can just redefine our style, or they
>>>> occur rarely enough for it not to matter.
>>>>
>>>> Some things that stand out as odd though (and make adoption difficult)
>>>> are the following blocks of code formatted with this .clang-format file,
>>>> using clang-format-3.8 built from trunk source yesterday.
>>>>
>>>> BasedOnStyle: LLVM
>>>>
>>>> AlignConsecutiveAssignments: true
>>>> AlignConsecutiveDeclarations: true
>>>> AllowShortCaseLabelsOnASingleLine: true
>>>> AllowShortFunctionsOnASingleLine: Inline
>>>> BinPackParameters: false
>>>> BinPackArguments: false
>>>> BraceWrapping:
>>>> IndentBraces: false
>>>> AfterNamespace: false
>>>> AfterClass: true
>>>> AfterControlStatement: true
>>>> AfterEnum: true
>>>> AfterFunction: true
>>>> AfterStruct: true
>>>> AfterUnion: true
>>>> BeforeCatch: true
>>>> BeforeElse: true
>>>> BreakBeforeBraces: Custom
>>>> ConstructorInitializerIndentWidth: 2
>>>> ContinuationIndentWidth: 2
>>>> ConstructorInitializerAllOnOneLineOrOnePerLine: true
>>>> MaxEmptyLinesToKeep: 1
>>>>
>>>> ----------------------------------------
>>>>
>>>> int * err = 0;
>>>> ino_t_xx dir_inode = 0;
>>>> gen_t dir_gen = 0;
>>>>
>>>> Here, the variables and equal-signs are lined up beautifully, but the
>>>> star isn't hard up against 'err' - which I would have expected given the
>>>> fact that LLVM sets PointerAlignment to Right. Looking into the
>>>> implementation (and doing some experiments), it looks like 'Right' just
>>>> means "no need to put a space to the right of a star" - but plenty of
>>>> spaces can be inserted to align the variable. Is this intentional, and
>>>> if
>>>> so, is there a plan to add a new option to align pointers/references to
>>>> the
>>>> right (as distinct from not-left like now)?
>>>>
>>>> Since (regrettably) in C/C++, "pointerness" is associated with the
>>>> variable and not the type, having the star hard up against the variable
>>>> seems to me to be something that a lot of people would want.
>>>>
>>>>
>>>> ----------------------------------------
>>>>
>>>> static int find_highest_index(ino_t base_inode,
>>>> gen_t base_gen,
>>>> int fd,
>>>> uint32_t *highest_index)
>>>>
>>>> This looks like a bug - if it aligns some of the parameters, it should
>>>> align all of them.
>>>>
>>>> ----------------------------------------
>>>>
>>>> static int find_highest_index(
>>>> ino_t base_inode, gen_t base_gen, int fd, uint32_t *highest_index,
>>>> bool
>>>> dummy)
>>>>
>>>> This looks like a bug too - I added an extra parameter with a short type
>>>> to demonstrate that the first and last parameters aren't aligned, but it
>>>> put them all on one line. If there is an extra configuration parameter
>>>> that
>>>> would prevent this, please let me know.
>>>>
>>>> ----------------------------------------
>>>>
>>>> static int find_highest_index(ino_t base_inode,
>>>> int fd,
>>>> uint32_t *highest_index,
>>>> bool dummy)
>>>>
>>>> Here is the example that shows the first and last parameter aren't
>>>> aligned, but the others are.
>>>>
>>>>
>>>> Thanks
>>>>
>>>> --
>>>> Graham St Jack | Software Engineer | Quantum
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=CwIGaQ&c=8S5idjlO_n28Ko3lg6lskTMwneSC-WqZ5EBTEEvDlkg&r=yTQSm-kpxQWFmaw_dZw3NDIbiHmjByJUaCZAObR4cjk&m=txXwxkJVYrSF9OKwEB6ccTSxCsEMnoTxVYXq8gtPE-U&s=YcA6gd67WO2JnSODQdhhCsw1x2uZE7WalB25sZMMRr0&e=
>>>>
>>>>
>>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_cfe-2Ddev_attachments_20151118_545bc757_attachment.html&d=CwIGaQ&c=8S5idjlO_n28Ko3lg6lskTMwneSC-WqZ5EBTEEvDlkg&r=yTQSm-kpxQWFmaw_dZw3NDIbiHmjByJUaCZAObR4cjk&m=txXwxkJVYrSF9OKwEB6ccTSxCsEMnoTxVYXq8gtPE-U&s=ZTepWq0tjqTSgDGjP2RD5sf5MP_xviz8zdwI9db_jyI&e=
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=CwIGaQ&c=8S5idjlO_n28Ko3lg6lskTMwneSC-WqZ5EBTEEvDlkg&r=yTQSm-kpxQWFmaw_dZw3NDIbiHmjByJUaCZAObR4cjk&m=txXwxkJVYrSF9OKwEB6ccTSxCsEMnoTxVYXq8gtPE-U&s=YcA6gd67WO2JnSODQdhhCsw1x2uZE7WalB25sZMMRr0&e=
>>
>>
>> ------------------------------
>>
>> End of cfe-dev Digest, Vol 101, Issue 110
>> *****************************************
>>
>
>
> --
> Graham St Jack | Software Engineer | Quantum | Office: 8304 8919 | Mobile: 0417
> 281 693
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151126/ad53787d/attachment.html>
More information about the cfe-dev
mailing list