Implict cast fix

[ChrisDodd]

• Allow implicit casts between serializable enums and their underlying type in action calls

[vlstill]

What part of the spec is this implementing? As far as I see 8.11.2 of the v1.2.4 spec allows only implicit casts of serializable enum → underlying type, but not the other way around. Your test seems to imply you have now allowed both.

[ChrisDodd]

Hmm -- it seems weird to allow implicit casts one way and not the other. I was originally just looking at the implicit cast from serializable enum to underlying type, but the way typechecking works, it ends up being symmetric.

[vlstill]

Hmm -- it seems weird to allow implicit casts one way and not the other. I was originally just looking at the implicit cast from serializable enum to underlying type, but the way typechecking works, it ends up being symmetric.

I would argue that for implicit casts the spec makes sense -- a seralizable-enum-typed variable is supposed to contain one of the named values, but an implicit cast from the underlying type would make it very easy to accidentally create a value that is not one of the named once. I think such a thing should be only for explicit casts.

[ChrisDodd]

Ok, I've managed to figure out how to get this to allow the implicit casts one way and not the other -- there's some confusion here between type unification (which is symmetric) and type checking (which is not), so it needs an extra type check to disallow the 'wrong' conversion.

[fruffy]

Can you elaborate on that bug? Maybe we can fix the DPDK back end.

[ChrisDodd]

Basically, the DPDK backend creates new code that is not type-correct, so a following TypeChecking pass tries to introduce new implicit casts, but fails as the readOnly flag is set. I'm not sure why it only fails after this change, as it seems like it should fail regardless. Specifically the incorrect added code is an action call where the actual argument type does not exactly match the formal parameter type (but can be converted implicitly). It seems that typeChecking is not correctly checking this case, and this change fixes that (as part of getting the serializable enum casts working)

I tried adding a additional TypeInferencing pass in the DPDK backend to introduce the implicit casts correctly, but that caused some other problems. This feels like a bit of a hack, leaving the code as semi-type-incorrect (not making the implicit cast explicit) when the readOnly flag is set.

[fruffy]

Which pass is this? Maybe we can fix the generation of this action call in the first place?

I think this is something the DPDK back end needs to fix before we add more workarounds to the type checker. The class is already complicated.

[ChrisDodd]

The problem is in DPDK::PrependPDotToActionArgs (line ~1318) where it is creating a ListExpression rather than a StructExpression to initialize a struct. The typechecker wants this to be a StructExpression, so will introduce a "cast" (actually rewrite the ListExpression as a StructExpression), which then causes a problem as it is running with readOnly = true (backend.cpp line 107). If I change that call to have readOnly = false, then it doesn't assert and just makes the change. However, it then has problems later in the backend with code that doesn't know what to do with a StructExpression.

Without my change, the typeChecker does not correctly type check action args, so it doesn't try to insert the conversion.

The easiest fix is probably just to add a call to P4::TypeInference with readOnly = false somewhere, and fix the backend code to understand a StructExpression.

[fruffy]

@usha1830 Could you take a look at this?

[fruffy]

#4553

[usha1830]

Sure. I will check this out.

[fruffy]

Tentatively approving. @vlstill any follow-up?