Similarly, two functions, controls, or parsers with the same signature but different bodies cause the latest p4test as of 2019-May-10 to give errors, but petr4 quietly accepts them. Attaching the programs for reference.

parsers-same-name1.p4.txt
functions-same-name1.p4.txt
controls-same-name1.p4.txt

This public version of petr4 (we have a development version that is private) only includes the parser. So what these examples show, assuming it's not a bug in our parser, is that the programs that the open-source C++ code is rejecting are being rejected in semantic analysis, not in the parser (which I believe Mihai conjectured).

We do have a type-checker in preparation, which we plan to release soon. It should give a complete front-end equivalent to the open-source C++ code.

Got it. I had been guessing that the current public petr4 had some semantic analysis as well. I will hold off on creating more issues like this unless I find something that looks amiss in petr4's syntax parsing.

Actually, this comment suggests that at least one of the examples should be a parse error.

p4lang/p4c#1932 (comment)

It may well be a bug in our parser...

The way I understood that comment of Mihai's is that he wishes some of those error messages were better, but it is difficult to make them clearer the way they use Bison and the lexer, I think by installing defined type names as new recognized lexer symbols.

Closing as a duplicate of #135