p4c: newtype declarations and functionsDeclarations will conflict once toplevel functions are supported

Let us consider the two following p4programs.

Example 1:

typedef bit id;

type id<type> (type x) {
  return x;
}

Example 2:

typedef bit id;

type id id2;

With p4-16 1.1 grammar, both are syntactically correct.

Both have the two-tokens-sequence type id where id is a TYPE_IDENTIFIER and type is the TYPE token; but in one case this corresponds to a nonTypeName followed by a name; and in the other case this corresponds to the type keyword of a newtype declaration. So, when the parser has read the TYPE token and looks ahead to TYPE_IDENTIFIER, it could either reduce a nonTypeName out of TYPE, of shift to recognize a newtype declaration.

Hence, there is a conflict.

This conflict is not yet observable in the compiler, as toplevel functions are not yet implemented. Hence for now, the compiler rejects the first example for the wrong reason: it doesn’t expect the opening parenthesis of a function definition.

But when support for toplevel function declarations is added, this conflict will arise.

---

If it is unclear, let me explain why the definition of function id is syntactically correct in example 1. The first time type appears, it specifies the return type of the function, and this is allowed because the return type can be a nonTypeName, as it can be a type parameter that has not been parsed yet, like here. Then there is id, that will be parsed as a TYPE_IDENTIFIER because of the previous typedef declaration; but that is ok because function names are allowed to be any name, so in particular a typeName. The second time type appears it is a type parameter, that can be a nonTypeName, so in particular type. The third time type appears, it is a typeRef, more specifically a typeName, since it was promoted as a type name by the parsed type parameter. The rest of the function declaration is less surprising.