This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new parser: error recovery needs work




--On Monday, January 13, 2003 03:46:43 PM -0800 Joe Buck <jbuck@synopsys.com> wrote:

The new parser doesn't produce useful diagnostics in the presence of
common errors.  Since the old parser did better, this is a regression.
To be honest, I'm somewhat unsympathetic.  Not because I think the error
messages are good, or because I think that we shouldn't do better, but
because it's hard to do better in some of these cases and because
we do noticably better in other cases -- the old parser just said
"parse error" a lot. :-)

It's also hard to do better without breaking legal programs; it takes
a lot of head-scratching to think of all the cases.

The new parser might want to use a strategy that goes something like this:
make a guess as to what was intended.  If a complete statement can be
parsed according to that guess, then keep it.  Optionally try a second
guess, if there is one available, otherwise skip to some synchronizing
token.
I'd prefer that we not introduce yet more backtracking.  Too complicated.

Treating "identifier_1 identifier_2" by saying "identifier_1 is not a
type" is an excellent idea.  Probably not too hard to implement,
either. :-)

Put these into PRs; I'll look at them when I've gotten through the
crashes and such.

Thanks,

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]