I will check the validation error. All the other tests pass.

In the test program for this PR, there are non-header fields of the struct type headers. This is something that the v1model architecture is documented not to support. Neither does the PSA architecture. For some reason that I have forgotten, it has become fairly common that a user-defined struct containing only headers type is one output of a parser, and a separate user-defined struct often called "user-defined metadata" is a separate out or inout struct type from parser to control, and control to deparser, for containing members with any type.

Are your changes intentionally trying to generalize this restriction? If so, I am curious why you want to do so?

Here is where the restriction is documented for the v1model architecture: https://github.com/p4lang/behavioral-model/blob/main/docs/simple_switch.md#restrictions-on-type-h

Here is the PR for the PSA specification planning to document this restriction for the PSA architecture: p4lang/p4-spec#722

In the test program for this PR, there are non-header fields of the struct type headers. This is something that the v1model architecture is documented not to support. Neither does the PSA architecture. For some reason that I have forgotten, it has become fairly common that a user-defined struct containing only headers type is one output of a parser, and a separate user-defined struct often called "user-defined metadata" is a separate out or inout struct type from parser to control, and control to deparser, for containing members with any type.

Are your changes intentionally trying to generalize this restriction? If so, I am curious why you want to do so?

Here is where the restriction is documented for the v1model architecture: https://github.com/p4lang/behavioral-model/blob/main/docs/simple_switch.md#restrictions-on-type-h

Here is the PR for the PSA specification planning to document this restriction for the PSA architecture: p4lang/p4-spec#722

@jafingerhut , headers contains field bits which is a header. I understood that this is a restriction, but this example works fine on the behavioral-model and that makes this restriction too general. Do you have some other examples which could be checked without this restriction on the behavioral-model?

I understand that it might be fairly straightforward to remove the restrictions on type H in v1model. Because the type M for user-defined metadata exists and is also available as output from the parser and input to the control, I don't see a motivating reason why the restriction on H should be removed -- just document that users put those in type M instead.

Digging through my memory, I am not sure, but one possible reason for having two separate user-defined types H and M is that their directions can be defined differently, e.g. out for H from parser, inout for M from parser.

I think that we can propose the same solution us I did it for log_msg. It could be some new pass which translates simple data types into another header. I will do it later with low priority.

@VolodymyrPeschanenkoIntel Are you still interested in pursuing these changes? Or perhaps OK to close this PR as abandoned? Note: If you do still wish to pursue it, I am still curious what the motivation for the generalization is. Perhaps it is simply "I know how to generalize it, so I wanted to?"