Re: Is CPP broken? (Re: Strange gcc error message)

[Zack Weinberg <zack at codesourcery dot com>]

On Mon, Oct 08, 2001 at 07:37:21PM +0100, Neil Booth wrote:
> Zack Weinberg wrote:-
> 
> > I think this will happen for any condition where cpp_start_read
> > returns an error: the constraint being enforced here is that whenever
> > yyparse returns 1, errorcount is nonzero.
> 
> Hmmm.  Why is this the case?  I had a quick skim, and cpplib should
> be setting its error count to non-zero.
> 
> So I'd guess that the front end breaks out in some kind of fast path,
> and doesn't do the cpp_errors() call to get the number of errors that
> it otherwise does.  In which case I'd rather fix it there.
> 
> Have I got this wrong?  Or maybe the current code is structured
> awkwardly so this isn't natural.

The check of NOT (errorcount XOR yyparse return value) happens
immediately after yyparse returns. We don't call cpp_errors until
finish_parse, which happens much later.

Another possibility is to return _success_ from yyparse if
cpp_start_read returns failure.  Then its immediate caller is happy,
and the error doesn't get lost because we do eventually adjust
errorcount from cpp_errors.  This isn't even really a lie - it is the
normal path for all errors which do not cause yyparse_1 to return
nonzero, which is most of them.

Yet another possibility is to forget about this check, which is very
old and of dubious value.  We could just have in toplev.c

  /* Call the parser, which parses the entire file
     (calling rest_of_compilation for each function).  */
  yyparse ();

  /* In case there were missing scope closers,
     get us back to the global binding level.  */
  while (! global_bindings_p ())
    poplevel (0, 0, 0);

and trust that all errors eventually get back to errorcount.
(Currently, that while loop is executed only if yyparse returns an
error, which strikes me as dangerous for languages that use
hand-written parsers and don't particularly want to pass error codes
back up.)

While we're at it we could call the parser entry point something other
than yyparse, which would let us get rid of some kludges in c-parse.in.

zw