for next time

[Matthew Fluet]

> > > One  thing  I  meant to ask about before, but clearly didn't: do the .S files
> > > produced really need to go through the preprocessor?
> >
> > Currently, yes, they do need to go through the preprocessor, but only for
> > the __LINE__ directive so that gc messages are printed correctly.
>
> OK, then I vote for fixing this and keeping the line number ourselves.  That
> will fix the other problem we had when compiling -g because of the debugger
> wanting to look at the .s file.

Fine by me, but how?  Bear in mind that the line number is an argument to
a function call to GC_gc, so that operand is generated during the
translation from Machine IL.  Then it's carried around for quite some time
before I print it out.

I guess I could add a line-num argument to the toString/layout functions
that print out the assembly, since I am counting lines for splitting.
There is a slight complication in accounting for the header comments,
since that will vary with the number of controls.

In the long run, I think a better solution would be to revise the layout
library itself to have this reflexive property; i.e., a layout function
would take file name/line number arguments for use with printing.
Actually, even better would be just to have layout primitives
Layout.lineNumber and Layout.fileName (and Layout.columnNumber?) which
could be embedded into layouts and would be instantiated by the layout
printers as appropriate.  There are some additional complications, in that
you really can't allow \n's in things being printed by Layout nor should
you allow any writing to the outfile between Layouts to it.  I guess that
could be taken care of by an abstract type of Layout outfile (which would
just be a normal outfile, maybe with current name, line & col number, but
types would only allow Layout to print to it).