Add arrays of non-header types

[ChrisDodd]

No description provided.

[jafingerhut]

Should we in this PR also define literal syntax for arrays, e.g. perhaps something like (typeRef[4]) {expr0, expr1, expr2, expr3}?

[jafingerhut]

In this section:

[#sec-uninitialized-values-and-writing-invalid-headers]
=== Reading uninitialized values and writing fields of invalid headers

there is an explicit statement about accessing elements of header stacks that are outside of range:

The result of reading a value in any of the situations below is that
some unspecified value will be used for that field.
[ ... ]
* reading a field of a header that is an element of a header stack,
  where the index is out of range for the header stack.

Should that be generalized to reading an element of an array where the index is out of range for the array?

Similarly later in that section for attempted writes to a header stack element it says:

If any of these kinds of writes are performed:
[ ... ]
* a write to a field in an element of a header stack, where the index
  is out of range
[ ... ]
then that write must not change any state that is currently defined in
the system, neither in header fields nor anywhere else.

Should that also be generalized to attempting to write to elements of an array where the index is out of bounds?

[vlstill]

Looks good to me, I agree we should have exact semantics of out-of-bounds access as suggested in #1360 (comment).

[kfcripps]

This opens up the possibility of having nested arrays, which could potentially complicate array / header stack processing in some passes. We might consider explicitly prohibiting nested arrays until there is real motivation to support them. Related discussion: p4lang/p4c#5115 (comment)

[ChrisDodd]

Most of the support for this is already in p4c -- last remaining piece is p4lang/p4c#5338

[jonathan-dilorenzo]

Ready for review and merging. @jonathan-dilorenzo and @jafingerhut to review.

[jonathan-dilorenzo]

Let's resolve the "error?" to error and make a note that this isn't done for any deep reason, but simply due to the lack of compelling use cases and the ability to change our minds in a non-breaking way.

[jaehyun1ee]

Considering typedefs which may alias header or header union types, e.g.,

header Hdr { bit<32> x }
typedef Hdr hhh;
... and somewhere else we use hhh[5], a header stack

"where typeRef is the name of a header or header union type" is a bit imprecise.

So maybe we can put:

A header stack type is defined as an array declaration where `typeRef` represents 

[jonathan-dilorenzo]

+1. I think that phrasing is quite nice.

[jonathan-dilorenzo]

Minor comments, but approving and will merge immediately upon fix.

[jonathan-dilorenzo]

nit: error*

[jonathan-dilorenzo]

+1. I think that phrasing is quite nice.