[cfe-dev] Question about clang-format
Graham St Jack via cfe-dev
cfe-dev at lists.llvm.org
Sun Nov 22 14:43:44 PST 2015
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
More information about the cfe-dev
mailing list