[cfe-dev] Question about clang-format

[Beren Minor via cfe-dev]

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;

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.

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
>> 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/20151118/545bc757/attachment.html>