This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Identifying source file locations.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]