This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ lexical analysis rework
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Eric Botcazou <ebotcazou at libertysurf dot fr>
- Cc: gcc-patches at gcc dot gnu dot org, Matt Austern <matt at lafstern dot org>, Steve Naroff <snaroff at apple dot com>
- Date: Sat, 15 Jan 2005 10:41:39 -0800
- Subject: Re: C++ lexical analysis rework
- References: <871xgw4azp.fsf@codesourcery.com><200501151050.05271.ebotcazou@libertysurf.fr>
Eric Botcazou <ebotcazou@libertysurf.fr> writes:
>> Here is the foreshadowed patch which speeds up the C++ front end's
>> lexical analysis phase. What it does is really quite simple: it has
>> (almost) all of the work that cpplib and c-lex.c do done at once, and
>> holds all the translation unit's tokens in a big buffer.
>
> I just discovered that this breaks DBX_USE_BINCL support:
...
> because dbxout.c relies on the ordered invocations of
> dbxout_start_source_file, dbxout_symbol and dbxout_end_source_file to
> implement it. Now dbxout_start_source_file and dbxout_end_source_file are
> invoked by the lexer, while dbxout_symbol is invoked by the parser.
...
> How do you think we can fix this? Should we "replay" the opening/closing of
> files in the parser (if this is ever possible)?
Yes. What ought to happen is, the cb_line_change and fe_file_change
logic should be completely disabled for C++, and what they do should
be moved to cp_lexer_set_source_position_from_token. C++ may want its
own versions of those hooks that record file open and close
information in the token array - I don't think we have that right now.
Matt was working on related issues. Such a change *might* be
acceptable for 4.0 if done very very carefully, and I don't have a
less-invasive suggestion, sorry.
zw