This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Identifying source file locations.
- To: Kenneth Almquist <kalmquist2 at hotmail dot com>
- Subject: Re: Identifying source file locations.
- From: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Date: Fri, 8 Jun 2001 20:07:58 +0100
- Cc: gcc at gcc dot gnu dot org
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.
> * It would be nice to have column information in most if not
> all error messages. We could retain column information
> at least until we generate RTL.
Yes.
> * The preprocessor complicates error reporting. We might
> associate two locations with each token that is the result of
> preprocessor expansion: the location of the preprocessor
> name which was expanded, and the location of the token
> in the #define directive.
Yes; I'm not sure what's best here. Either both, or have it
specifiable on the command line to cut down on verbosity. I know
people do want to be able to be pointed to the macro where a given
token came from.
> 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.
Neil.