Re: Diagnostic clean ups

[Gabriel Dos Reis <gdr at codesourcery dot com>]

Neil Booth <neil@daikokuya.demon.co.uk> writes:

[...]

| > | In summary, a location should be specifiable by a pointer to a
| > | structure (I guess) containing a line and column, and for the
| > | C front ends either a cpp_token ** or a size_t for indexing into
| > | the token array (see thread referenced below).
| > 
| > Hmm, IMHO that is too much for a location concept.  Why can't we reuse
| > the IDENTIFIER_POINTER associated with a _DECL as far as cpp_token is
| > concerned? 
| 
| Why is a single size_t too much?  You could make it an unsigned int
| if you really wanted.
| 
| I'm not quite sure what you're referring to, but a location need not
| having anything to do with a declaration.

My mental model is that a declaration has a location, and that we
don't deal with a location as an entity in itself but it happens as a
piece of information about a declaration which we usually dealt with.
Thus if we have a declaration, we have its location -- and that
corresponds to almost all uses of locations --; but I don't see any
need to consider a location by itself.

What part of cpplib paraticularities am I missing?

| The "upper" parts of the front end should only need an array index for
| syntax error or other parser-level diagnostics, but when things start
| getting stored in more permanent locations like a DECL node, then the
| front end should convert it to a line and column number and save that,
| so it doesn't matter if the token array disappears.  This convertion
| loses information about what macro was in progress, but I doubt that's
| important by that stage: the information is probably for debug output or
| something, rather than for diagnostics.

Thanks for the explanation.  My concern is: Why isn't it sufficient to
have a one-way link from a CPP_TOKEN to a location, i.e. in which
circumstances is it necessary to have a link back to a CPP_TOKEN from
a location?

-- Gaby