Feature: Extend rules mechanism to further levels of abstraction (long term).

[DaveMcEwan]

This describes a long-term project for extending the rules mechanism in svlint.
As discussed briefly here, it would be nice to have rules for different levels of SystemVerilog abstraction.

It would be cool to (eventually, long-term) extend svlint something like this:

• src/textrules/*.rs: Operate on lines of text, e.g. "Are any lines longer than 80?".
• src/pprules/*.rs: Operate on the preprocessor parse tree, e.g. "Do macro names contain lowercase letters?".
• src/rules/*.rs: Operate on the source-text parse tree, i.e. what's already in place.
• src/comprules/*.rs: Operate on semantics of a single source-text description (module, package, program, etc.), e.g. "Are any signals undeclared before use?".
• src/elabrules/*.rs: Operate on semantics of multiple/combined source-text descriptions, e.g. "Are any ports unconnected on a module instance?"

Notes:

• textrules is fairly easy to implement and shouldn't add too much to the resultant svlint executable.
  There is a (very) rough outline of required changes on this branch (yes, I know it's called pprules, not textrules).
• comprules sounds like the most difficult one, and would massively increase the size of the svlint executable.
  My thinking is to implement the complicated semantics in a separate crate and require a flag to load/run.
  That crate would be something like svdata, but with much more development.
  This would also allow things like Operation precedence not being followed when creating parse tree sv-parser#62 to be addressed.
• elabrules should be straightforward once comprules is in place... I think... maybe!

My rough plan is currently, in order:

• Address most of the outstanding issues on svlint.
• Develop svlint_installer into something workable for deployment at my day job.
• Implement textrules.
• Address some bug issues on sv-parser.
• Implement pprules.
• Restart development on svdata (or its successor) while keeping comprules and elabrules in mind.

Any advice or feedback would be appreciated :)

[dalance]

As discussed briefly #224 (comment), it would be nice to have rules for different levels of SystemVerilog abstraction.

I agree the proposed levels.

Restart development on svdata (or its successor) while keeping comprules and elabrules in mind.

The current parse tree is "Concrete Syntax Tree" including comment, white space,,.
This is suitable to syntax level linter and formatter.
To implement semantic analyzer, "Abstract Syntax Tree" or "Intermediate Representation" may be required.