This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: #pragma interface/implementation broken if --enable-mapped-location
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 23 Sep 2004 19:08:09 -0700
- Subject: Re: #pragma interface/implementation broken if --enable-mapped-location
- References: <41537AFC.4070709@bothner.com>
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