Re: Confusing errormessage with implicit typename

[Joe Buck <Joe dot Buck at synopsys dot COM>]

On Fri, Sep 03, 2004 at 05:28:43PM -0700, James E Wilson wrote:
> Nicolas Pavlidis wrote:
> > /home/pavnic/projects/converter/src/utilities/factory.h:151: warning:
> > implicit typename is deprecated, please see the documentation for
> > details 
> 
> The deprecated feature has been removed, and as a result, we can no 
> longer give this warning.  Since we have no code to support implicit 
> typename, it is difficult to impossible to give an error complaining 
> about when it occurs.

I don't believe that this is true.  I think that it is possible to improve
the new parser to give better diagnostics.  Mark's focus when he did the
new parser was, naturally, to correctly compile valid code.  The work of
generating really good diagnostics for commonly encountered parse errors
simply has not been done.  If anything, it's easier to do a good job with
a recursive descent parser: if a valid parse cannot proceed, try to make a
good guess about the user's intention.

Competing compilers give error messages like 'foo appears to be a type,
but has not been declared to be a type' in cases like this, and Gerald and
I pushed to get a hack into the old C++ parser to do exactly this.

Consider the following one-line file:

vector<int> foo;

Up through 3.3.x we get

Q.C:1: 'vector' is used as a type, but is not defined as a type.

3.4.x gives

Q.C:1: error: expected constructor, destructor, or type conversion before '<' token
Q.C:1: error: expected `,' or `;' before '<' token

The parser could do a better job here, and as this example shows,
something else besides a constructor, destructor, or type conversion can
appear before a '<': a template name can.