Generalized array support

[ChrisDodd]

First change relaxes frontend checks to allow arrays in general as per p4lang/p4-spec#1320. Non-header arrays only support indexing, not any other header stack operations

Second change adds support for C-style array declarators, with the array size after the name instead of before it.

[jafingerhut]

Nice! The test cases look interesting. As usual (unforunately), I haven't attempted to review the C++ implementation code.

What is the behavior if you attempt to use an index expression that is not a compile-time known value?

I could imagine trying to allow that if the index expression type was bit<W>, and the array had size at least 2^W, since you can pretty easily statically guarantee that the index is in range in that case. Anything fancier than that and it starts to go down the rabbit hole of what can be proved about the range of values at compile time.

[ChrisDodd]

What is the behavior if you attempt to use an index expression that is not a compile-time known value?

I could imagine trying to allow that if the index expression type was bit<W>, and the array had size at least 2^W, since you can pretty easily statically guarantee that the index is in range in that case. Anything fancier than that and it starts to go down the rabbit hole of what can be proved about the range of values at compile time.

The frontend/midend won't do anything about it, but I would imaging that many targets would be unable to support non-constant indexes and the backend would reject it. It is not clear what a target that could support non-constant indexes could/should do about out of range indexes. In all of this, an array is the same as a header stack. This really just makes header stacks a special case of arrays -- they support some additional functions that arrays of non-header/header union types do not.

[kfcripps]

Could you please add positive and/or error test cases similar to the following to demonstrate what is expected when the array type is an array type or contains array types?

struct S {
    bit<16> f1;
    bit<8>[16] nested_arr;
    bit<16> f2;
}

header data_t {
    bit<32>     f1;
    bit<32>     f2;
    bit<16>     h1;
    bit<16>     h2;
    S[16]  arr;
}
...
    hdr.data.arr[x].nested_arr[y] = ...;
    ... = hdr.data.arr[z].nested_arr[w];
...

and (if the grammar allows it (I did not look very closely at changes to p4parser.ypp)):

header data_t {
    bit<32>     f1;
    bit<32>     f2;
    bit<16>     h1;
    bit<16>     h2;
    bit<8>[16][16]  arr;
}
...
    hdr.data.arr[x][y] = ...;
    ... = hdr.data.arr[z][w];
...