Andrew Pinski

I could see the struct being flatten into the parameters and then using param.field as the names of the actions parameters. That would be an easy spec change for P4Runtime...

> Should we merge this? What is the reason for this change? The fix looks correct to me. we using F_SETFD and oring in FD_CLOEXEC so that should be used...

> But the spec says something different. See https://p4.org/p4-spec/docs/P4-16-working-spec.html#sec-computing-control-names Which does not list & expressions in the table for keys and generated names. Should this table be updated with what...

> For what it's worth, Petr4's local type inference scheme handles this. My compiler is able to handle it too which as I do constant folding explicitly doing parsing of...

This is what the spec says: ``` At least one state, named start, must be present in any parser. A parser may not define two states with the same name....

This is another one which is why I said the specifications in this area seems fuzzy: ``` #include action a(in bit r, in bit t = 1, bit tt) {}...

Note the specifications does have this: ``` Actions can also be explicitly invoked using function call syntax, either from a control block or from another action. In this case, values...

Maybe a related issue is instantiation using a typedef does not work either: ``` parser p() { state start { transition accept; } } typedef p tt; parser p1() {...

So there is no way to have two names for a parser/control then? What about extern?

The problem I have with parser not being a type but some fuzzy type/decl, is the whole grammer of the language is wrong then. typeName "." APPLY Does not work...