This is the mail archive of the
mailing list for the GCC project.
Re: Identifying source file locations.
- To: kalmquist2 at hotmail dot com (Kenneth Almquist)
- Subject: Re: Identifying source file locations.
- From: Per Bothner <per at bothner dot com>
- Date: 09 Jun 2001 21:23:38 -0700
- Cc: gcc at gcc dot gnu dot org
- References: <200106100329.f5A3TBi09457@mail.monmouth.com>
firstname.lastname@example.org (Kenneth Almquist) writes:
> 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.
Two things to keep in mind:
(1) The Java front-end can compile multiple source files in one
invocation of the compiler. Which leads to the quetion: Should
the line numbers be re-set when starting a new top-level file
(i.e. one specified on the command line), or should you just keep
incrementing the counter?
(2) The Java front-end already keeps track of column numbers.
So it needs to be updated to any new scheme.
(3) Is this "separate data structure" something global, or is
it part of the tree structure? If the former, if does further
complicate (future) efforts to make gcc re-entrant? In other
words, I'd like it to be possible to assign meaning to tree
nodes without consulting an external shared data structure.
This becoems essential for a re-entrant compiler. One way to
do this is for top-level (or function-level) tree nodes
to point to their mapping table. Then this can be carries
along while processing sub-tree nodes.
> In addition making the location 16 bits
I proposed some time ago using IIRC 12 bits for a column number,
and 20 bits for a line number. That is equally compact, and
does not require an external mapping table.
> this approach allows error messages to be sorted.
Which is more usable: Sort by "logical order" or sort by
"source order". I suspect the latter.
> 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).
It seems better for the error-reporting processor to (re-) read the
files as needed.
> 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
Well, logically we should maintain a source range, for statements as
well as expressions.