[cfe-dev] Question about clang-format

[Daniel Jasper via cfe-dev]

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/20151113/32221496/attachment.html>