Add type nesting rules for extern, parser, control, and package types

[jaehyun1ee]

I would like to propose a change to the spec following the discussion made in #1324.
This adds the cases for extern / parser / control / package types for the type nesting rule defined in section 7.2.8.

In summary,

• It disallows extern / parser / control / package types from being nested inside a header / header union / struct / tuple / list / header stack.
• It allows extern / parser / control / package to be aliased by typedef, but disallows for type.

[jafingerhut]

vlstill agreed to review. Some discussion in 2025-Jan-13 LDWG meeting. If vlstill approves, the other members of the LDWG meeting could think of no objections to merging with vlstill's approval.

[jaehyun1ee]

Just double-checked with the behavior of p4c,

extern E {}
// struct S { E e; }
// type E e_new;
parser P() { state start {} }
// struct S { P p; }
// type P p_new;
control C() { apply {} }
// struct S { C c; }
// type C c_new;
package Pkg();
// struct S { Pkg pkg; }
// type Pkg pkg_new;

all commented lines result in the program being rejected by the frontend.

[vlstill]

I agree with the changes, except for some formatting issues.

---

With type I think for these types of entities it is pretty clear the newly defined type would be (almost) unusable, and we already disallow a lot of types in type. So I am fine with disallowing those. I can see much more use for type X = string or type X = int than for these, but that is for a different discussion :-).

Side note: With these changes, it makes even less sense to prohibit typedef on match_kind and void. Maybe we should just say that any type can be typedef'ed.

[vlstill]

I think these should not be in backticks. The rule should be something like: if it is an actual piece of code/if it is type (possibly generic) than it is in backticks, but if it is a type "category" (like "header unions") than it should be plain text. For this second table, that was preserved in the asciidoc, but for the first one it probably got mistakenly reformated in the conversion -- compare https://p4.org/p4-spec/docs/p4-16-working-draft.html#sec-type-nesting and https://p4.org/wp-content/uploads/2024/10/P4-16-spec-v1.2.5.html#sec-type-nesting. I think the formatting in 1.2.5 is correct, while the draft is wrong in the first table.

I suggest we keep consistent in each of the tables separately in this PR and then file a follow-on PR to fix format in the first table (I can do that once this is merged).

[ChrisDodd]

My thought is we should have backticks around (only) things that literally might appear in a P4 program. So "enumueration types" is definitely wrong, but maybe should have "struct types"?

[jaehyun1ee]

I agree to both: (1) having a separate PR to fix the backticks consistently and (2) putting [ header types, header stacks, header unions, and struct types ].