Re: Identifying source file locations.

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Kenneth Almquist wrote:-

> I want to number the lines coming out of the file inclusion pass
> sequentially, and have a separate data structure to map these to
> filename:line_number values.  In addition making the location 16 bits
> smaller, this approach allows error messages to be sorted.

OK, good idea.  I like that.

> Also, it requires the source code to be kept in memory so that the
> column can be computed.

Not necessarily.  For the C front end, we only need the source file
around the area we're currently compiling.  Sometimes we refer back
(e.g. for duplicate definition errors to the original definition) but
for that I think just the location of the original definition is
enough - printing just the line of 2nd definition, where we found the
error, should suffice.  Thus, for example, dropping include files from
memory, and having only recent program text in memory could well be
enough for the C front end (assuming a copy of the line that is
printed is made when creating the error message).

For C++ I can see this getting more complicated with template
instantiations.  So templates might want to store the program text of
their declaration so that it can be referred back to.

Or, it might just be better (and certainly simpler) to do as you say -
keep everything in memory and too bad for those who don't have enough.

> (The column computation scans the line for tab characters, since
> those have a varying width.)

The C family front ends get tokens, which have a line and column
attached.  At present, you need to call a cpplib function to get it,
but Zack argued persuasively a few months back that tokens should
actually contain that information as part of their data structure.
The column is already tab-adjusted by cpplib.

> GNAT keeps all source code in memory so that it can display verbose
> error messages (which include the text of the line containing the
> error).  However, the C front end doesn't support verbose error
> messages, and even if they were added it's likely that the majority
> of users would turn them off.  So I agree with your idea of having a
> separate 16 bit column number.

I don't quite follow you there.

>     column format - 1 bit:  Currently always zero.
> 
>     column - 16 bits:  The column number, staring with 1.

> If verbose error messages are implemented for the C front end, we will
> want to display the results of a macro expansion if an error occurs
> within text resulting from a macro replacement.  If column format is
> set to 1, then the column value identifies a preprocessor token output
> by the preprocessor.  A table which is created only when verbose error
> message are requested allows the preprocessor output tokens to be
> mapped back to the source code.

I don't follow your distinction between column format being 0 or 1.
Is it a boolean to flag whether a token is the result of a macro
expansion or not?

Thanks for having thought about this and having lots of ideas!

Neil.