preprocessor directives indentation

[Trass3r]

Bugzilla Link	17362
Resolution	FIXED
Resolved on	Jan 19, 2018 09:47
Version	trunk
OS	All
CC	@aardappel,@catskul,@gnzlbg,@zmodem,@jbreitbart

Extended Description

clang-format just puts all directives at line start.

But I want to have:
#ifdef _MSC_VER
#pragma warning (push, 0)
...
#endif

while some people seem to like:
#if ...

define ...

#endif

Also I indent stuff like #pragmas (OpenMP for example) in the code while I always put typical #ifs etc. to switch code at line start.
Haven't tested that yet, just came to my mind.

[llvmbot]

I also miss an option to indent (or at least don't mess up with) those #defines.
Furthermore I found a strange behavior when using "ColumnLimit: 0"
some linebreak and a "" is added..
e.g.:

#if defined(PAUL)

define TINA __farm(export)

#else

define PAUL __farm(import)

#endif

becomes:

#if defined(PAUL)
#define TINA
__farm(export)
#else
#define PAUL
__farm(import)
#endif

[llvmbot]

One of the problems here is that nobody really wants to indent header guards and yet it is unclear why they form a special case and exactly how to recognize them.

The ColumnLimit-0 problem has been fixed last week, you might need an update.

[Trass3r]

Not sure what you mean. To my knowledge clang itself does exactly that as well and treats header guards specially.

[Trass3r]

I think a related issue is that you may not want a namespace spanning the entire file to be indented but want it for short namespaces with forward declarations for example.

[llvmbot]

One of the problems here is that nobody really wants to indent header guards
and yet it is unclear why they form a special case and exactly how to
recognize them.

The ColumnLimit-0 problem has been fixed last week, you might need an update.

I did get my clang-format via this page: http://llvm.org/builds/ . Is this page kept up to date, or how should I update clang-format ? I only use this single tool, so I am not very familiar with the whole process and funtionality of llvm and clang.

[llvmbot]

+hans (as bugzilla apparently doens't handle email replies well ;)

This should be reasonably up-to-date (the svn revision number should be encoded in the file names on that site), I don't know of a good way to keep them auto-updated though... Perhaps hans can share his insights...

[zmodem]

+hans (as bugzilla apparently doens't handle email replies well ;)

This should be reasonably up-to-date (the svn revision number should be
encoded in the file names on that site), I don't know of a good way to keep
them auto-updated though... Perhaps hans can share his insights...

I generally try to put up a new build each week, but haven't done so the past couple of weeks because of holidays.

clang-format doesn't auto-update itself. I don't think we'd want to do something like that ourselves, but we'd probably get this for free if we publish clang-format on the Visual Studio Gallery.

[llvmbot]

thank you, I am up to the newest version.
Back to topic:

Daniel Jasper:
"One of the problems here is that nobody really wants to indent header guards and yet it is unclear why they form a special case and exactly how to recognize them."

Trasser:
"Not sure what you mean. To my knowledge clang itself does exactly that as well and treats header guards specially."

So if indenting for header guards is not wanted, is or will there be an option that ignores header guards, so that an existing format isn't touched ?

[llvmbot]

I think nobody wants to indent in header guards, but I might be wrong.

[llvmbot]

*** Bug llvm/llvm-bugzilla-archive#19673 has been marked as a duplicate of this bug. ***

[llvmbot]

You could always add a flag for the user to specify whether they want to indent inside the header guards.

[aardappel]

Please support indentation options specific to being inside a class or function (as opposed to top level or namespaces, which are best left as-input).

Styles I've seen used:

void f() {
#ifdef ...
g();
#endif
}

void f() {

ifdef ...

g();

endif

}

void f() {

ifdef ...

    g();

endif

}

void f() {
#ifdef ...
g();
#endif
}

void f() {
#ifdef ...
g();
#endif
}

[llvmbot]

indent provides processor indentation as follows:

$ man indent | less -pppi

-ppin, --preprocessor-indentationn
    Specify the indentation for preprocessor conditional statements.


This  option  can  be  used  to  request that preprocessor conditional statements can be indented by to given number of spaces, for example with the
  option ‘-ppi 3’

    #if X
    #if Y
    #define Z 1
    #else
    #define Z 0
    #endif
    #endif
  becomes
    #if X
    #   if Y
    #      define Z 1
    #   else
    #      define Z 0
    #   endif
    #endif

Also, indent provides a way to keep the current spacing:

$ man indent | less -plps

-lps, --leave-preprocessor-space
    Leave space between ‘#’ and preprocessor directive.

Something similar could be really useful.

[aardappel]

To keep it simple, maybe just add a way to keep the existing indentation of any preprocessor statements?

[llvmbot]

No, clang-format is fundamentally not built to keep things as they are. If you don't want your preprocessor definitions formatted, the don't call clang-format on them. We have spent a lot of effort on editor and VCS integrations to make this really easy for you.

This most certainly is not a release blocker. It is a feature request over the currently released version of clang-format.