Style: don't break compiling freetype-errors.cc

Style: don't break compiling freetype-errors.cc

- Given a "define blah {" line, we *don't* want to move the { to
  the next line.

- given a:
    =
   include "foo.h"
    ;
  don't move the include onto the = line, or the ; onto the
  include line.

[Graham Percival (old account), 2010-09-10 19:46:57]

I'd appreciate it if a python guru / regex person  could take a quick glance at
this.  These changes will stop fixcc.py rendering lily/freetype-errors.cc
uncompilable, but this is the most complicated regex I've ever attempted (which
doesn't say much; I've never needed to use them before).

This doesn't imply that we will necessarily be using an automatic style program,
nor that we will use fixcc.py even if we decide to use such a program.  This is
just part of the homework that should be done before we can have a sensible,
well-informed debate about the question.

This isn't an urgent issue.

[perpeduumimmobile, 2010-09-11 07:02:55]

On 2010/09/10 19:46:57, Graham Percival wrote:
> a python guru / regex person [...]
That's not me...

(from the issue description)
> - Given a "define blah {" line, we *don't* want to move the { to
>   the next line.
> 
> - given a:
>     =
>    include "foo.h"
>     ;
>   don't move the include onto the = line, or the ; onto the
>   include line.

Wouldn't it be easier to just say
- if a line belongs to a preprocessor statement
  (i.e. it either starts with "#" or
        each of the lines before end with "\", and the first line
        of those starts with "#")
then leave it alone (dont merge another line on this, don't take some characters
out to the next)?  This would solve all those preprocessor related issues, and
seems easier.

If there's a "positive list" of changes, say,
- "# include\t\t<foobar>" => "#include <foobar>",
then those could of course be included as separate cases.

Typically only the three groups #include, #define / #undef and #if / #ifdef /
#endif make out nearly all of the preprocessor directives (unless there are a
lot of special optimizations like OpenMP use or compiler/platform-dependent
performance tweaks).  Do we really want to care about the others at the risk of
running into compiling issues?

[Graham Percival (old account), 2010-09-11 11:34:07]

On 2010/09/11 07:02:55, perpeduumimmobile wrote:
> Wouldn't it be easier to just say
> - if a line belongs to a preprocessor statement
>   (i.e. it either starts with "#" or
>         each of the lines before end with "\", and the first line
>         of those starts with "#")
> then leave it alone (dont merge another line on this, don't take some
characters
> out to the next)?  This would solve all those preprocessor related issues, and
> seems easier.

How could that be done?  I'm not sufficiently familiar with fixcc.py to spot
this immediately.  The regexes sometimes span multiple lines, so I'm sure that
it doesn't just go through and modify each line individually.
 
> Typically only the three groups #include, #define / #undef and #if / #ifdef /
> #endif make out nearly all of the preprocessor directives (unless there are a
> lot of special optimizations like OpenMP use or compiler/platform-dependent
> performance tweaks).  Do we really want to care about the others at the risk
of
> running into compiling issues?

I honestly don't think that we're going to keep fixcc.py, so I don't think it's
worth future-proofing it to that extent.  Don't get me wrong -- if we were going
to keep it, it would definitely be worth looking into that change.  But in these
circumstances, I think it would be more trouble than it's worth.

Cheers,
- Graham

[Graham Percival (old account), 2010-10-02 15:49:29]

I just checked a second-order diff (i.e. produce a diff by running an unpatched
fixcc, then produce a diff by running the patched fixcc, then compare those
diffs), and the only two changes are:
1) don't change
    */
    ;
into:
    */;
(this seems like a very good change)

2) keep lily/freetype-error.cc compilable
(which was the whole point of this)


If I don't hear any screams otherwise in the next few days, I'll go ahead and
push this patch.  NB: I'm _only_ talking about modifying fixcc.py, not running
it.  In fact, I doubt that we'll ever run fixcc.py on master.