This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Identifying source file locations.
- To: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Subject: Re: Identifying source file locations.
- From: kalmquist2 at hotmail dot com (Kenneth Almquist)
- Date: Sun, 10 Jun 2001 13:53:43 -0400 (EDT)
- Cc: gcc at gcc dot gnu dot org
Neil Booth wrote:
> 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?
It's a boolean flag indicating whether the column field contains a
column number or identifies a token. In the latter case, you get
the column number by looking up the token.
Let me give an example of what I was thinking of for a verbose
error mode, modelled after the verbose error mode for the GNAT
front end. The example used the following defines:
#define NELEM 32
#define ARRAY_SIZE (NELEM ** sizeof(int))
The second defintion is wrong because there should be one asterisk,
not two. Later on in the code the following statement appears.
array = malloc(ARRAY_SIZE);
In normal (non-verbose) mode, this will produce an error message like:
tte4.c:9:20: invalid type argument of `unary *'
In verbose mode, we show the preprocessor expansion of ARRAY_SIZE
and the point to the error location within the expansion.
Compiling: tte4.c
9. array = malloc(ARRAY_SIZE);
|
(32 ** sizeof(int))
|
>>> invalid type argument of `unary *'
To print this error message, we use the column field as an index
into a data object representing the second "*" token. This
object points to a second object containing a list of all the
tokens resulting from expanding ARRAY_SIZE, as well as the
number of the column where ARRAY_SIZE appears.
A semi-verbose mode might contain a reference back to the definition
of ARRAY_SIZE rather than printing the expansion, as in:
tte4.c:9:20 <= tte4.c:4:31: invalid type argument of `unary *'
I don't have plans to implement this stuff, but it seems useful
enough that I don't want a design which will rule it out.
> Thanks for having thought about this and having lots of ideas!
I appreciate your support.
Kenneth Almquist