Check enum label value

[taichi-ishitani]

There is the limitation below for enum lebel values.
Need to check if this limitation is satisfied.

From IEEE 1800-2023 6.19.2 Enumerated type ranges

Originally posted by @taichi-ishitani in #771 (comment)

[nblei]

Adding to this:

I think it would be nice to support the "name ranges". For example,

enum State {
    Ready,
    Run<6>,
    Done
}

[taichi-ishitani]

Adding to this:

I think it would be nice to support the "name ranges". For example,

enum State {
    Ready,
    Run<6>,
    Done
}

Yes, I agree but I think you should create a new ticket for this feature.

[taichi-ishitani]

For ease of checking enum label values, how about the following enum value rule?

• If an enum label value includes x/z then all other enum label values should be specified explicitly.

[nblei]

I think this is a place where we'd want to follow the SV LRM very closely.

An enum variable or identifier will be automatically cast to a numerical type if used in a numeric expression.

Looking at the LRM, there are a number of things we still need to check for.

1. An x or z assignment to an enum without an explicit data type or a 2-bit data type is an error: e.g., enum E { ... or enum E: bit<4> { .... cannot have a x or z assignment.
2. An unassigned enum name which follows an x or z assignment is illegal. E.g., enum E: logic<2> { IDLE=2'b00, XX=2'bxx, S1, S2 } is illegal.
3. Enum names must be unique, including automatically inferred values. Thus, enum ShouldError: u32 { S0, S1, S2 = 1, S3, } is illegal .
4. The enum datatype must be larger enough for all of its variant. I thought we were checking this, but I just tested it and we're not

Value encodings are determined is as follows:

If no value is provided, then the first defined element is given value 0 and subsequent elements are incremented from the previous element. For enum type ranges, each instance of the range is treated as a separate element.