msys2 removed the gperf package from the base-devel package collection[1].
Add gperf explicitly to the dependency list, without this the Windows
CI will fail.
[1] 085698dce3
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently the Windows build generates a warning
=> WARNING: MINGW_INSTALLS is deprecated, use MINGW_ARCH instead
Make this change to the CI workflow file.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
With the development version bumped to v13 the regression tests runner
expects a `regress-v13.list`. Provide one, which is just a copy of the
`regress-v12.list` for now.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that it is possible to use the `super` keyword to access properties
and methods of the base class that exist with the same name in current
class.
Also check that `this.super` is supported as an alternative to `super` and
has the same behavior.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SystemVerilog allows to use either `super` or `this.super` to access the
base class. Both have the same behavior. Currently only `super` is
supported, also add support for `this.super`.
To support it the parser has to be changed slightly and move the trailing
`.` after the `this` or `super` keywords into the `implicit_class_handle`
parser rule. This is necessary to avoid reduce conflicts in the grammar.
As a side effect `super` can no longer be used as a standalone identifier.
E.g. `return super;` But that's not legal SystemVerilog anyway, so that is
OK.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SystemVerilog allows to use the `super` keyword to access properties and
methods of a base class. This is useful if there is for example an
identifier with the same name in the current class as in the base class and
the code wants to access the base class identifier.
To support this a bit of refactoring is required. Currently properties are
internally referenced by name, this does not work if there are multiple
properties of the same. Instead reference properties always by index.
In addition when looking up an identifier that resolves to an object return
both the type and the object itself. This is necessary since both `this`
and `super` resolve to the same object, but each with a different type.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Internally the special THIS_TOKEN("@") and SUPER_TOKEN("#") are used
to represent the special `this` and `super` keywords in a component
name.
When printing an identifier replace the tokens with their keywords.
This generates nicer error and debug messages.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The PEIdent elaborate_expr() and elaborate_lval() are sort of open-coding
the path traversal implemented by the new symbol_search() using the old
symbol_search().
Switch them over to use the new symbol search as it is better at handling
the corner cases and is also less code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
One variant did, the other variant didn't. As well as being a trap for
the unwary, this gets in the way of using yywarn/VLwarn for non-fatal
"sorry" messages.
The function prototypes both use the name VLwarn, with a macro definition
providing the alias to yywarn. But one of the variant implementations was
named yywarn. Make it consistent with the function prototype.
Always prefix with "error: ". Capitalise the first word of the main
message unless it's a Verilog keyword. Use VLerror() in preference
to direct output to cerr.
Check that typed constructors calls are supported. Also check various
invalid usages of typed constructor calls and check that an error is
reported.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
By default when creating a new class object the type of the object is
determined by the type of the target.
SystemVerilog also allows to explicitly specify the type of the object to
be created. The specified class still needs to be assignment compatible
with the target. This is e.g. useful to construct an object of a derived
class of the target. E.g.
```
class B; ... endclass
class C extends B; ... endclass
B b;
b = C::new;
```
Add support for this to the parser as well as handling it during
elaboration.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Class methods with static lifetime are not allowed in SystemVerilog. Report
an error when such a method is declared.
Note that this is different from static class methods
E.g.
```
class C;
task static t; endtask // Class method with static lifetime, forbidden
static task t; endtask // Static class method, allowed
```
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Up to 1800-2017 the grammar in the LRM allowed an optional lifetime
qualifier for class declarations. Icarus supports this and uses this as the
default lifetime for methods of the class. But the LRM never specified what
this qualifier should do actually actually. Starting with 1800-2023 the
qualifier will be removed from the grammar[1].
Furthermore the LRM states that methods of a class are supposed to have
automatic storage and static storage is forbidden.
This currently works in Icarus for the most part since the liftime attached
to class methods is ignored during elaboration in most places. Where it
does not work is for variable initializers where it results in broken code
being generated and vvp crashes at runtime. E.g.
```
class C;
task t;
int x = 10;
endtask
endclass
```
Keep the optional lifetime qualifier for classes in the grammar for now, to
ensure backwards compatibility in case somebody is actually using it. But
ignore it and print a warning if it is specified.
In addition set the default lifetime for all classes to automatic. This
makes sure that variable initialization in classes works as expected.
[1] https://accellera.mantishub.io/view.php?id=3561
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Normally the preprocessor will catch these and report them as undefined
macros. But in case the compiler is run without the preprocessor, also
catch them in the compiler scanner. This will ensure the scanner properly
rejects directives that have additional garbage characters tacked on the
end.
Verilog compiler directives are free-form and, subject to semantic rules,
can appear anywhere in the source code. Whilst it is common practice to
write them on a separate line, we should handle all legal syntax.
Clean up warnings that show up on newer compilers. Many of these warnings
are related to obsolete c library features or language features. This does
not clear up warnings in code generated by bison or flex.
It was common practice in the past to just declare a port direction
and declare it as a vector in a subsequent type declaration. Versions
of the standard up to and including 1364-2005 include an example that
does this (e.g. 1364-2005 section 12.3.7). Users may have old or
third-party code that they can't or don't want to modify, so allow
the warning to be suppressed by including it in the anachronisms
category.
Check various different scenarios for array compatibility in continuous
array assign. Both testing cases that should work and cases that should
fail.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently there is no error checking for continuous assignments to unpacked
arrays. If the lvalue and rvalue net are not compatible undefined behavior
occurs. For some types of incompatibility it will crash during elaboration,
for others it will crash during simulation, and for some it will just work,
even though the assignment is not allowed by the standard.
Implement checking to ensure the two nets are compatible as required by the
standard and report an error otherwise.
Two arrays are considered to be compatible if their element types are
equivalent, they have the same number of ranges and each range has the same
number of elements.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that it is possible to assign an object to another object that is of
a type of any of its base classes. Also check that an error is reported if
this is not the case.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SystemVerilog allows objects to be assigned to a variable that is a base
type of the objects type.
E.g.
```
class B; endclass
Class C extends B; endclass
C c = new
B b = c;
```
Add a type_compatibility() method for netclass_t that allows these kinds of
assignments.
This already works fine in vvp since, as SystemVerilog does not support
multiple inheritance, properties will always be at the same offset in the
base class and the inheriting class.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that it is possible to use a function with a return type as a
statement by using a void cast.
Also check that trying to void cast a void function, a task or an
expression results in an error.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SystemVerilog has explicit support for calling a function
as a statement. This is allowed when the function call is encapsulated in
`void'(...)`. E.g. `void'(f(1, 2, 3));`
We already support calling function calls as statements without the void
cast and emit a warning when doing so.
Adding support for void casts only requires to update the parser to handle
the void cast and then do not emit the warning if a function is called as
a statement as part of a void cast.
Void casting a task or void function call is not allowed and will generate
an elaboration error.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Stephen Williams
Stephen Williams
Lars-Peter Clausen
Martin Whitaker