Improve errors where declared types are expected

[kfcripps]

When the user supplies a token which is not a declared type, where a declared type is expected, the parser produces various types of syntax errors, many of which are not as accurate and helpful as they could be. I would also argue that this type of error is not really a "syntax error," but this point is less important than the first.

Here are just a few examples, but there are certainly others that can be found by looking through the grammar in p4parser.ypp.

• An invalid instantiation, such as UndeclaredType() x; produces the error "syntax error, unexpected (."

• An invalid variableDeclaration, such as UndeclaredType x; produces the error "syntax error, unexpected ;, expecting (."

• An invalid typedefDeclaration, such as typedef UndeclaredType NewType;, produces the error "syntax error, unexpected IDENTIFIER, expecting ENUM or HEADER or HEADER_UNION or STRUCT."

• An invalid structField, such as

  struct A {
  UndeclaredType f;
  }

  produces the error "syntax error, unexpected IDENTIFIER "UndeclaredType"."

I would expect most of the above errors to be more along the lines of: "error: Declaration for UndeclaredType not found."

I think that this is a fairly common type of user error (not just in P4, but in all typed programming languages), so it would be nice for these errors to be improved upon, if it is not terribly difficult to do so. :)

[mihaibudiu]

All these errors are default errors produced by bison. I personally don't know how to improve on them, but I agree it would be nice to have nicer error messages.

[jafingerhut]

Related issue: https://github.com/p4lang/p4c/issues/4813

[jafingerhut]

A related comment on one technique to improve some error messages like these, and difficulties that one can encounter in using this approach, from Chris Dodd here: https://github.com/p4lang/p4c/pull/4812#issuecomment-2231758727

"In general, to improve these parse errors, you need to add code (rules) to the bison parser that matches in the problematic cases and then emits a more specific/better error. Doing this without introducing conflicts and breaking things that should work is sometimes tricky."