This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
#pragma interface/implementation broken if --enable-mapped-location
- From: Per Bothner <per at bothner dot com>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 23 Sep 2004 18:40:12 -0700
- Subject: #pragma interface/implementation broken if --enable-mapped-location
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.
Zack, how do you want to handle this?
--
--Per Bothner
per@bothner.com http://per.bothner.com/