Enable `const` identifiers in bit slice expressions, and anywhere else local compile-time known values are allowed

[jafingerhut]

Here is an example test program that exhibits this issue:

$ git clone https://github.com/jafingerhut/p4-guide
$ cd p4-guide/loop-test-progs
$ p4test err-const-is-not-compile-time-known-value1.p4 
err-const-is-not-compile-time-known-value1.p4(57): [--Werror=type-error] error: i: slice bit index values must be constants
            n[i:i] = 1;
              ^

$ p4test --version
p4test
Version 1.2.4.16 (SHA: d2006d52e BUILD: RELEASE)

This change was made to the language spec recently: https://github.com/p4lang/p4-spec/pull/1307

Thus according to the spec, the following code is legal:

    const bit<8> lo = 2;
    const bit<8> hi = lo + 3;
    bit<4> x;
    bit<8> y;
    x = y[hi:lo];

In some test programs I have tried this works fine, but in others it gives an error. I have not tried to get to the root cause of the difference between such programs.

Note: Technically the language spec enhancement also allows const values to be used in any place where a local compile-time known value is required, but a bit slice hi or lo expression are the only ones I know of off the top of my head.

[jafingerhut]

Hmmm. I may be imagining that I tried something like this in the past month or two and it failed, but it seems to be working for a test P4 program (attached) that has something like the above code snippet at its core, so perhaps I am wrong, and p4c already supports this. issue4920-bmv2.p4.txt

[ChrisDodd]

It does require the explicit const -- that allows the folding to happen directly without any dataflow analysis to prove that there are no intervening assignments to the variable.

[jafingerhut]

AI for Andy: Add a test program, probably the one attached to an issue above, as a new p4c test program, that can be used to verify that future compiler changes do not break this already-working behavior.