[RFC][4.4] Conversion of tree.h STRIP_* macros into static inline functions
Thu Dec 20 18:07:00 GMT 2007
>>>>> "Diego" == Diego Novillo <firstname.lastname@example.org> writes:
Diego> On Dec 19, 2007 2:21 PM, Tom Tromey <email@example.com> wrote:
>> IMO we should pick a set of GNU indent flags and declare that to be
>> our official coding style. Then developers can run indent before
>> patch submission and be confident in the results.
Diego> Yes! I'm all for mechanically-imposed indenting styles. Even if it
Diego> looks like someone sneezed on the screen. I take consistency over
Encouraged by this, I experimented with GNU indent yesterday. I ran
it over gcc/java, using both 'indent -gnu' and 'indent -gnu -bs'. (I
went through all the documented indent options and I think the closest
fit for us is actually 'indent -gnu -bs -nsc'.)
Unfortunately, I think the result is still not suitable for us. There
are a number of problems. Some are minor, but others are pretty
* I once had it emit an error and truncate a file. This is a show
* We need to pass a -T option for every typedef. Otherwise some
things are formatted oddly. For instance, without '-T tree', a
declaration might look like "tree * foo" (instead of "tree *foo").
This isn't a huge problem but it does mean we'd have to maintain a
list of typedefs, or live with weird formatting in some places.
* There is no way to get it to handle certain spaces in the gcc-style.
There's no option for "no space after !". It always formats
bitfields with no spaces around the ":".
* It gets confused by some gcc macros. A GTY or a VEC will mess up
indentation for parts of a file. FOR_EACH_BB and the like are not
formatted "loop-like". Finally, it doesn't handle attributes very
* lang-specs.h came out looking very bad.
I'll try reporting some of this to the indent maintainers and see what
they come up with.
More information about the Gcc-patches