[RFC][4.4] Conversion of tree.h STRIP_* macros into static inline functions

Tom Tromey tromey@redhat.com
Thu Dec 20 18:07:00 GMT 2007

>>>>> "Diego" == Diego Novillo <dnovillo@google.com> writes:

Diego> On Dec 19, 2007 2:21 PM, Tom Tromey <tromey@redhat.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
Diego> beauty.

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
  stopping bug.

* 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 mailing list