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.
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 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>
When calling non-void functions or non-void methods of built-in types as a
task a warning is issued. But when calling a non-void method of a user
defined class as a task an error is generated.
Be consistent here and generate a warning in both cases.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Unpacked array dimensions that are specified with only a single size value
(C-style unpacked arrays) have a $left of 0 and a $right of size - 1. E.g.
`x[10]` is equivalent to `x[0:9]`. This is defined in the LRM (1800-2017)
section 7.4.2 ("Unpacked arrays").
Currently it is implemented the other way around. There are a few contexts
where this distinction matters. For example array to array assignments,
which are supposed to be done left-to-right.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that an error is reported when either calling a task or a void
function as part of an expression.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Calling a task as part of an expression should report an error. The current
implementation uses `func_def()` and if that returns nullptr will report
the error. But `func_def()` will trigger an assert if the underlying scope
is not a function.
Make sure to first check that the scope is actually a function before
trying to call `func_def()`. If the scope is not a function report an
error.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Unlike normal functions void functions can not be called as part of an
expression. Trying so will currently hit an internal assert.
Make sure an error is reported instead.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
It is not allowed to create objects of virtual classes. Currently the
virtual keyword is accepted by the parser, but otherwise ignored.
Keep track of whether a class is virtual and generate an error when the
class new operator is used for a virtual type.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that a sign, width or type cast expression that contains an automatic
term is detected as such and can not be used as the left-hand side in a
procedural continuous assignment.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
If the base expression of a cast expression has an automatic term then the
cast expression itself has an automatic term.
Make sure this is implemented so that an error is properly reported when
using such an expression in a context where automatic variables are not
allowed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
With the recent refactorings pform_make_task_ports_vec() and
do_make_task_ports() are now very similar.
Consolidate them into a single function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The ivl_variable_type_t in PWire is now only used for passing the base type
for vector types to the elaboration stage. But we can query the base the
from the vector_type_t itself. If the there is no data_type_t set for the
PWire the base type will default to IVL_VT_LOGIC.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For loops may have empty initialization statements. In that case some things
can't be done, such as loop unrolling or synthesis, but otherwise it is a
valid thing to do. So generate the correct code in this case.
Check that it is possible to use a packed scope type identifier for the
type of a class property when the class is defined in the unit scope. This
makes sure that the elaboration is done in an order so that the type is
available when the class property is elaborated.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Check that it is possible to use a forward declared class type as the type
of a property in another class.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Martin Whitaker
Stephen Williams
Stephen Williams
Lars-Peter Clausen