Feature request: Waiver to ignore an error

[eddygta17]

A single rule can be omitted by changing the configuration file, but in case only a single error need to be omitted, it can be added to a waiver file to be excluded. While this can be manually dealt with for small projects, for larger projects it would be efficient to have a waiver file which can ignore some errors.

[DaveMcEwan]

You can use special comments to disable syntax rules around specific lines.
https://github.com/dalance/svlint/blob/master/md/manual-introduction.md#textrules-and-syntaxrules-sections
Does that help your usecase? If not, perhaps you can give some examples to show what you mean?
Where you need flexible, I'd use a collection of regex's to waive/signoff lots of messages, just like you would for other tools.

[eddygta17]

I found what I meant in verible and Vivado. Let me explain it with verible.

The linter in verible has 2 options for waiver:

1. In file waiver
2. External file waiver

The method you mentioned is absolutely fine in case of 'in file waiver'. The feature I intend to have is 'external file waiver'.

Creating an external file with these commands and passing to the linter would ignore that rule for those lines.

waive --rule=rule-name-1 --line=10
waive --rule=rule-name-2 --line=5:10
waive --rule=rule-name-3 --regex="^\s*abc$"
waive --rule=rule-name-4 --line=42 --location=".*some_file.*"

'In file waiver' has a limitation that the source file needs to be modified, while 'External file waiver' has the limitation that the line numbers need to be changed whenever the source file changes.

[DaveMcEwan]

Ok, I see what you mean. Personally, I don't think that sort of thing should be in this tool.
As you say, the waiver file(s) needs to be manually updated with all the source file(s), which I don't like for 3 reasons:

1. Git merging breaks waivers based on line numbers.
2. It's not completely obvious exactly how it should work.

• How do you prevent malicious/incompetent users from waiving too broadly like ^.*$? Do you waive/signoff the waivers.
• Which flavour of regex should the waivers use? Basic, extended, PCRE, Python, Rust's re, Rust's fancy_regex, ...? Whatever you choose, there will be complaints that it doesn't do quite what users expect. If you choose to support lookahead/lookbehind assertions, how do you protect remote machines from DoS attacks/mistakes?

3. That functionality is better suited (in my opinion) to an external tool. For example, I wrote this very simple Python script to work with the output of several tools from Synopsys, Cadence, and Xilinx. Basically, give it the tool's output and a waiver file (containing a list of regex expressions) then say it passes if nothing is printed on STDOUT.

If I assume I could find a neat approach that's easy to explain (fully, in a small amount of words) and works nicely with version control, I have another few concerns:

• Where should the regex/waivers be specified? A separate file, perhaps with one waiver per line of plain text? As part of a TOML config/ruleset? It doesn't sound like a big deal, but it will really affect usability, especially if we want to change things later.
• Should users be able to share waiver files, and if so, how? If they can, this will be abused and IPs will be distributed with waivers instead of fixing the code. I they can't, I suspect there will be complaints feature requests until they are sharable.
• Preprocessor directives (include, define, etc.) can break things in an amazing variety of ways!

Sorry if this seems all doom and gloom! Clearly other tools like verible can do similar things - I just can't see how to do it right for svlint :p