When creating an enum type it must be added to the scope where it is
declared so it can later be elaborated and the enum and its names can be
referenced in expressions.
In addition the names of the enum must be added to the lexor scope so that
name collisions are detected and can be reported as errors.
This is done with pform_put_enum_type_in_scope() function.
At the moment the function is called from two different places
* When adding a typedef of a enum type
* When creating a signal of a enum type
In addition the enum_type_t is added to a class scope `enum_sets` when
declaring a enum property in a class. But this only makes sure that the
enum gets elaborated, its names are not added to the lexor scope.
This works fine for the most part, but breaks for a few corner cases.
E.g. it is possible to declare a enum type as part of the subtype of
another packed type such as structs or packed arrays. E.g.
```
struct packed {
enum {
A
} e;
} s;
```
This is not covered by either of the cases above and neither do the names
of the enum get added to the lexor scope, nor is the enum type elaborated.
Another corner case that is currently not working is declaring a class
property where the type is a typedef of a enum that is declared outside of
the class. In this case the enum is elaborated again inside the class
scope. E.g. the below is supposed to work, but fails with an already
declared symbol error.
```
typedef enum {
A
} e_t;
class C;
typedef enum {
A
} e1;
e_t e2;
endclass
```
In addition since for enums declared in classes they are only added to
`enum_sets`, but names are not added to the lexor scope, it is possible to
declare a different symbol in the class scope with the same name.
E.g. the following elaborates fine
```
class C;
enum {
A
} e;
typedef int A;
endclass
```
To fix this call pform_put_enum_type_in_scope() when the enum_type_t is
created in the parser. This makes sure that it is handled the same
regardless where the type is declared or used.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Refactor the enum rule by adding a enum_base_type rule which handles the
type specific initialization. This allows to keep the non-type specific
parts in a common rule, which makes it easier to modify in future changes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When something goes wrong when parsing a struct member, e.g. the type does
not exist, a nullptr is added to the struct member list. This will cause a
crash when iterating over the list.
E.g.
```
struct packed {
logc x;
} s;
```
Add a check so that nullptr members are not added to the list.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the common data_type_or_implicit rules to support type
definitions for parameters. This eliminates a bunch of special
rules in parse.y, and opens the door for parameters having
more complex types.
This.new is not allowed.
super.new beyond the first statement is not allowed.
And while I'm at it, clean up the use of "@" and "#" in
the code as tokens for this and super.
Unless explicitly declared a wire an enum output port is of variable type
and should be marked as IMPLICT_REG.
Currently this is only done when the base type of the enum is `logic`. But
it should be done for all enums regardless of their base type.
Without this change for example the following snippet
```
typedef enum {
A,
B
} E;
module M (
input E ei,
output E eo
);
always_comb eo = ei;
endmodule
```
fails with the following error message
test_enum.sv:11: error: eo is not a valid l-value in M.
test_enum.sv:8: : eo is declared here as wire.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For functions without a port list in parantheses, declarations are optional in SystemVerilog.
This is true even in IEEE1800-2005, but not in IEEE1364-2005
The unique, unique0, and priority keywords can decorate case statements
to tell the run time (or synthesis) to do extra tests (or make extra
assumptions). These tests are not implemented in the vvp run time, but
now the decorations make it to the code generators.
Explicit imports should always conflict with local declarations using
the same name. Wildcard imports only conflict if they are referenced
before a local declaration with the same name.
This also unifies the detection of identifier conflicts.
Lars-Peter Clausen
Martin Whitaker
Cary R
Stephen Williams
Purdea Andrei