Re: patch in setting statement location

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Sat, 2 Apr 2005, Per Bothner wrote:

> At least one testcase was failing when --enable-mapped-location
> due to setting the statement location from that of its first token.
> That no longer works now that we copy location information from
> teh cpp token on each token.  Specifically, the first token is
> post-macro-expansion, and thus might be from a macro replacement text.
> 
> Instead, using the input_location seems to work.

I don't think this patch can be correct.  The parser nowhere uses 
input_location explicitly, always preferring the location of a particular 
token so as not to be affected by internal details such as the amount of 
lookahead used for particular constructs.  I see no reason why this 
particular place should be different from all the others using the 
location of a given token, and think that in general all C front end 
diagnostics should eventually move to passing an explicit location, 
derived from a known token, rather than relying on where input_location 
happens to be.  If diagnostics are desired for the location where the 
macro is expanded, the proper fix is to give the token the location of 
expansion rather than of the macro definition, i.e. fix c_lex_one_token; 
I'd think this should be considered fallout from your patch in revision 
2.5.

Bug 17964, wrong error message location for C++, ran into much the same 
problem when Zack attempted to fix it 
<http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00394.html>.  I think that 
in order to fix that bug for 4.0, and this bug before USE_MAPPED_LOCATION 
becomes the only way, we need a way to get cpplib to mark token from macro 
expansions with the location of the expansion rather than of the macro 
definition, and then revisit for 4.1 after USE_MAPPED_LOCATION is the only 
way what the best way is for diagnostics to show both the macro expansion 
and definition locations.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)