File-extension language option not consistently applied
module testdo1(input do); endmoduleThis uses 'do' as a signal name, so you use +1364-1995ext+v to force .v files to be compiled a Verilog. This generates a SYMRSVDWORD warning but that's ok. Now suppose you have testdo2.v and compile with +1364-1995ext+v:
module testdo2(input do); testdo3 m(do); endmodulewhich automatically pulls in testdo3.v:
module testdo3(input do); endmoduleThis is now faulted with
%Error: testdo3.v:1: Unexpected "do": "do" is a SystemVerilog keyword misused as an identifier.It looks like the language override is only being applied to explicitly named source files and not to other sources. This isn't specific to the name "do", it affects other words like "byte".
This isn't a mixed-language design, it's pure Verilog, but it seems there is no way to get Verilator to compile as pure Verilog.
#1 Updated by Wilson Snyder 9 months ago
- Status changed from New to AskedReporter
I don't see anything immediately obviously wrong, but certainly wouldn't surprise me if there are issues.
Could you provide a self-test in verilator test_regress format showing the problem?
Also perhaps attempt a patch? V3Options::fileLanguage would be a good place to start looking.
It looks like the extension-to-keywords mapping is being applied too early.
When Verilator needs to get a definition for another module, it calls V3ParseImp::parseFile() with 'modfilename' set to the bare module name, and that then calls V3PreShell::preprocOpen(), which calls V3Options::filePath() to turn the module name into a file name. But by that time the `begin_keywords line has already been stacked up on the input and the actual file extension isn't checked.
So in the above example it calls parseFile("testdo3"), generates `begin_keywords "1800-2017", and then later on testdo3.v is found and parsed as SystemVerilog.
I guess this could be fixed simply by moving the file extension check to preprocOpen(), but maybe the language determination belongs in V3Options.
Also available in: Atom