#pragma interface/implementation broken if --enable-mapped-location

[Zack Weinberg]

Per Bothner <per@bothner.com> writes:

> Some change in the last week or so broke support for
> #pragma interface/implementation in the --enable-mapped-location
> case. This breaks building libjava/java/lang/natClass.cc.
>
> What appears to be happening is this:
> The #pragma interface in Class.h is deferred until the current
> file (as given by input_location) is natClass.cc.  At that point
> cp_lexer_handle_pragma calls cp_lexer_set_source_position_from_token,
> which nicely sets the input_location to the saved Class.h.  After a
> few more calls we call do_pragms, but with the defer_pragmas flag
> turned off, so we get to:
>
>   if (p && (p->is_internal || !CPP_OPTION (pfile, defer_pragmas)))
>     {
>       /* Since the handler below doesn't get the line number, that it
> 	 might need for diagnostics, make sure it has the right
> 	 numbers in place.  */
>       if (pfile->cb.line_change)
> 	(*pfile->cb.line_change) (pfile, pragma_token, false);
>       (*p->u.handler) (pfile);
>     }
>
> The pragma_token has a location in natClass.cc even though the
> original (deferred) pragma was in Class.h.  So the call to
> line_change sets the input_location to the location in natClass.cc,
> undoing the effect of cp_lexer_set_source_position_from_token.
> Hence the #pragma interface doesn't work.
>
> The same thing happens in the --disable-mapped-location case,
> but it happens to "accidentally" work:  In that case the cb_line_change
> function (in c-lex.c) just changes the input_line, leaving the
> input_filename unchanged.  The resulting input_location is
> non-sensical, but #pragma interface doesn't care.
>
> My quick-and-dirty fix to remove the cb.line_change call.  I'll try
> rebuilding with that.

We can't take out the cb.line_change call, that will mess up the C
front end.

My question is why is the pragma_token's location wrong?  That would
seem to be the real bug.

zw