Trailing comma in port-list results in hard-to-understand error message

[hzeller]

Here is an example of a common mistake (as it should be allowed in the language in the first place), an extra comma at the end of a port-list:

module foo(
  input a,
);
endmodule

The resulting error message is hard to understand:

[SYNTX:PA0207] t.sv:3: Syntax error: mismatched input ')' expecting {'.', 'interface', 'virtual', 'type', 'input', 'output', 'inout', 'ref', 'enum', 'struct', 'union', 'string', 'chandle', 'event', '[', 'byte', 'shortint', 'int', 'longint', 'integer', 'time', 'bit', 'logic', 'reg', 'shortreal', 'real', 'realtime', 'supply0', 'supply1', 'tri', 'triand', 'trior', 'tri0', 'tri1', 'wire', 'uwire', 'wand', 'wor', 'trireg', 'signed', 'unsigned', 'interconnect', 'var', DOLLAR_UNIT, '(*', 'this', DOLLAR_ROOT, 'randomize', 'sample', Escaped_identifier, Simple_identifier},
);
^-- ./slpp_all/work/t.sv:3:0:.

Similar for parameters

module foo #(
   parameter integer FOO=42,
)();
endmodule

The resulting syntax error is also not easy to understand:

[SYNTX:PA0207] t.sv:3: Syntax error: no viable alternative at input 'module foo #(\n   parameter integer FOO=42,\n)',
)();
^-- ./slpp_all/work/t.sv:3:0:.

I suggest to allow the trailing comma in the parser and then just report it one level up. We can report a syntax error there.

(we should maybe support some gentle syntax extensions to SystemVerilog: it should actually be allowed to have a trailing comma, and it should be recommended practice in SV programming, once we get the standard changed :) This can be implemented by having the above a simple warning instead of error but still go on with the rest of processing).

[Thomasb81]

Those message come directly from antlr. For the first one the tool provide you the list of expect token allowed instead of ')'. For the second one the tool go so deeper in rules specialization that he did not found any proposition to help you to fix the input document.

(we should maybe support some gentle syntax extensions to SystemVerilog: it should actually be allowed to have a trailing comma, and it should be recommended practice in SV programming, once we get the standard changed :)

What do you exactly mean by "once we get the standard changed" ?

Do you have some example of tool allowing such trailing comma and supporting verilog or systemVerilog ? The BNF of systemVerilog is quite explicit : it is not allowed. I am not in favor for such change until next SV release change that.

Having say this, I should admit, it is a common copy/past composition mistake.

[hzeller]

I think similar to gcc, that extends the feature-set to things that simply make sense to then be later adopted by the standards -- we should push for reasonable changes like this. Maybe hidden behind a flag.

These days, it is the open source tools such as gcc and clang that drive the standards committee decisions. We should work towards that in SystemVerilog land.

[Thomasb81]

I can agree with that, unfortunately today there is not yet the same weight of user needing open source C and C++ compiler than SystemVerilog so such day can take a while. About more than 10 years speaking about gcc. Concerning clang, do not forget the big companies names behind supporting the project.

Also the process of standard contribution is probably different between ISO and IEEE ...

[hzeller]

Things take time. But not starting them will not make them happen.

[alaindargelas]

I'm in favor of language extensions, but this particular one, I'm not so sure.

Several points on the language extensions though, the entire set of tools in the case of C++ that are "must-have" is the compiler itself, then the "nice to have tools" are valgrind, coverity, and a few other code analyzers. In the case of SystemVerilog, the "must-have tools" in an ASIC flows are:

• Synthesis
• Simulator (along with waveform viewer, and optional state machine visualizer)
• Formal Equivalence Checker
• Linter

and then there are the nice-to have, schematic viewer, advanced Design level Analyzers... For the Standard to evolve, you have to convince the "must-have" tool providers (Synopsys/Mentor/Cadence).

On the non-usefulness of the error from Antlr, the Antlr error messages are post-processed by Surelog and with a bit of ideas and work, depending on context, Surelog could could make the messages much more useful. Today they are plainly forwarded to the user, with just a bit of formatting and augmented with the snippet of source code. A lot more could be done.

[alaindargelas]

VCS:

Following verilog source has syntax error : "design.sv", 4: token is ')' ); ^

Incisive: ); | ncvlog: *E,NULLLP (design.sv,4|0): empty/illegal list of ports [12.3.4(IEEE-2001)].

Questa: ** Error: (vlog-13038) design.sv(4): near ")": Missing port in ansi port list.

Riviera: No warning, no error, it compiles.

[hzeller]

I think if we can get an error "superfluous comma at end of port list" or "superfluous comma at end of parameter list" for the other case, that would be great.

[Thomasb81]

That's sound to be a lot of work just to turn an already existing message pretty understandable into what you expect by conveniency.

Note that error message in most tools, do not discuss about the trailing comma but that something is missing before the opening bracket : same behavior than Surelog. That's because when a parser found a next valid token for a rule, it consumes it, in a way it is hard to change his decision : it is most probable that next unrecognized token is wrong since everything before was ok. In the context of your example, the current grammar rule run until the last valid and recognized token : the trailing comma and what come next is an unrecognized token at this position : opening bracket.

The best is probably to familiarize yourself with the kind of message produce, that are quite understandable once you learn how to decode them.