Error, Warning, Diag message classification

[Blebowski]

Hi,

I was wondering if NVC could support some sort of grouping/classification of error/warning/diag messages.
An error would be uniquely identified by e.g. an abbreviation and number. An abbreviation
would correspond to the processing phase of the code (e.g. VHDAN_ for VHDL analysis,
VHDSM_ for semantic checks, VLGAN_ for Verilog analysis, ELAB_ for elaboration,
CGEN_ for code generation, etc...)

The format of message then would be e.g.:
Error (ELAB_4): example.vhd:39 - invalid formal name for unconstrained port test_enable

The errors/warning/diag messages would be defined somewhere in an array and distinguished
by an enum e.g:

typedef enum {
     VHDAN_1     = 1,
     VHDAN_2     = 2,
     ...
     ELAB_1        = 1000,
     ELAB_2        = 1001,
     ...
} diag_code_t;

This implementation would allow stuff like:

• Generating list of all possible errors/warnings into the documentation.
• Option to downgrade/upgrade errors to warning (or vice-versa) on command line (e.g. nvc -EnoVHDAN_2).

Sure, not all errors are down-gradable to warning, some make it impossible to continue. However, many cases
would benefit from this configurability.

This is similar to what OpenROAD is doing, and what can be done in GCC by -W* switches.

What do you think?

[nickg]

I can see it's useful for warnings if they can be disabled individually, although I prefer strings as identifiers like GCC (e.g. -Wconversion) over numbers. But at the moment NVC doesn't generate many warnings.

For error messages I'd rather make the message itself as descriptive as possible rather than adding an ID that has to be looked up separately. There's already some support for adding extra information to diagnostics (e.g. diag_hint() and diag_lrm()) and that could be extended to link to documentation if necessary. Having to make a new ID each time is also a burden when adding new error messages, and I'd like to make that as simple as possible as more/better errors is ultimately what improves the user experience.

[Blebowski]

I see. Of course for user this should behave transparently. User would see the error "code" plus the error message.
The error code would be only a complementary information allowing user to possibly manipulate the given message.

The "added information" that could potentially be part of manual, would be e.g. an examples of how to fix such error
message, examples when the error occurs, or what could potentially be done with the error message (apart from
fixing the problem in the source code). I have had a good experience with this type of error categorization in
Physical Design tools, where without good manual its almost impossible to find out what the tool wants from you.
Sure, for compiler this is slightly different since the grammar tells you what is needed, but still, there might be cases
where this may be helpful.

Implementation wise, yes, this may be difficult. All messages would need to be defined centrally somewhere,
and the code throwing the message would only refer to the "ID", and pass varargs. Alternatively, the
messages could stay defined across in the code, but the compile process would scrap all calls to diag,
and create the list of messages at compile time. Defining any kind of metadata for the message would then
be hard.

Promoting warnings to errors is important when you want to enforce writing your code as strict as possible.
OTOH, if you inherit a code-base that you for some reasons can't change, it may be good to demote the
some errors to warnings. E.g. an attempt to override non-existing generic on sub-instance currently throws
an error. IMHO it may be good to have an option to demote this to warning.