Open jbylicki opened 1 year ago
Dialect support is something we could implement by for instance not parsing int
as a TK_int
token, but as an identifier and then have the parser figure it out.
Another approach (which might be better) could be to prime the lexer to not parse keywords depending on the dialect (there might be even a bug open for this).
I like the approach the Verilator lexer is doing, selectively lexing things depending on the chosen dialect. Maybe something like that could be useful.
Paging @fangism who probably has thought through some of the options.
Here https://cs.opensource.google/verible/verible/+/master:verilog/parser/verilog.y;drc=18abf1511dd48625c25028f67910a71d4e27fcba;l=759
you can find a collection of keywords that can also be identifiers in some contexts. In some easy cases, you could allow a keyword like int
to be an identifier. I suspect that int
may be tricky because types appear in many places in the grammar.
Describe the bug The syntax checker rejects a case where there are variables named
int
. While it technically is invalid SystemVerilog syntax, it is valid Verilog (since there was no typeint
, it was introduced in SV), and legacy projects still do use it. Even the smoke-tests have a case (innontrivial-mips
) where there is a syntax error produced because of it.Additionally, there are more errors produced due to this issue as the parser later rejects other tokens as being invalid.
To Reproduce
Actual behavior:
Expected behavior
Definitely it should be mentioned that this is valid only in Verilog, but the input should be checked. While legacy Verilog is not listed as supported, crashing (
rc=1
) on legacy code bases is not ideal. Do we want to support legacy Verilog? If so, we should probably introduce tooling around it. @hzeller what do you think?