Re: Identifying source file locations.

[kalmquist2 at hotmail dot com (Kenneth Almquist)]

Neil Booth wrote:
> Kenneth Almquist wrote:-

>>  * The tree should contain file name information.  Otherwise, error
>>    messages and debugging info can contain the wrong filename if
>>    #line or #include directives are present.
>
> Yup.  The filename should probably be a 16-bit index into a file
> array.  And it should probably contain the column of the starting
> line as well, for diagnostic purposes.

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.

>> The Ada front end (GNAT) represents source locations as a 32 bit
>> character position.
>
> That would require a large table, with an entry per non-empty source
> line.  I'm not sure that's any better than just using 48 bits for line
> and column and keeping it simple.  Since C has include files and such,
> a translation unit can get pretty enormous.

Also, it requires the source code to be kept in memory so that the
column can be computed.  (The column computation scans the line for
tab characters, since those have a varying width.)  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.

Putting this together, my idea is to represent source locations
using the following fields:

    line - 31 bits:  After file inclusion is performed, lines are
        numbered sequentially, ignoring file changes and #line
        directives.  A mapping function will map a "line" value to
        a file name and the number of the line within the file.

    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.

For statements, the tree should contain the following location
information:

    start_loc - 48 bits.  As defined above.

    end_line_offset - 15 bits?  Adding this to the "line" field of
        start_loc gives the line number of the last line of the
        statement.

    first_on_line - 1 bit.  This is set if the statement is the
        first statement on the line.  This means that when producing
        DWARF debugging information the column field can be set to
        zero.  (See my preceding message to the gcc list.)

For expression nodes, the tree should contain a location.  For a
conditional expression (expr? expr : expr) it seems to make the most
sense to have the location of the node be the location of the question
mark.
				Kenneth Almquist