Andy Fingerhut

Here is a proposed list of access restrictions that p4c could check for access to v1model standard_metadata fields. Preferably someone else should review it to see if there is anything...

In the interests of moving things forward here, if `@pure` and `@noSideEffects` are the only two annotations that we really have good use cases for taking advantage of in compiler...

The parts of these changes that add the `@pure` annotation, and changes to v1model.p4 and psa.p4 architectures to add `@pure` and `@noSideEffects` annotations, have been merged with this commit: https://github.com/p4lang/p4c/commit/301411d7ee4cc22d381a923037f840f575635aa2...

@ChrisDodd @mihaibudiu Does it seem reasonable to close this, since `@pure` and `@noSideEffects` have been in the P4 spec and p4c implementation for a couple of years now, and no...

Hmmm. This .pp file appears like it was #include'd by another P4 test program at some point in the past, one named psa-portid-using-newtype2.p4. That file was renamed v1model-portid-using-newtype2.p4, but accidentally...

Out of curiosity, does this use of the word "model" correspond to a P4_16 architecture?

I have collected most of the P4 programs given on issues that I have added the label control_plane_api to (currently 4 of these open as of 2022-Jan-19 - link to...

Copying a note from Mihai Budiu to this open issue, so it remains easily found while this issue is still open: "There is one more wrinkle to consider: for P4-14...

By any chance, is this intended to address an issue like the one described in this issue? https://github.com/p4lang/p4c/issues/2755 One of the example programs on that issue has identical `@name` annotations...

I tried building p4c with the proposed changes on this PR after 3 commits, and ran it locally on my system. It fails for a very simple P4 program with...