Feature: Add naming convention warnings (--naming-check flag)

[TinyuengKwan]

Summary

This PR introduces optional naming convention checks to the Sail compiler. It adds a new pass that verifies if identifiers follow standard Sail naming conventions, helping to maintain code consistency.

Changes

• New Flages:
  • --naming-check: Enables the naming checks. Violations are reported as warnings by default.
  • --naming-check-strict: Enables checks and treats violations as errors.
• Conventions Enforced:
  • Types, Records, Variants, Enums: TitleCase
  • Functions, Variables,Arguments: snake_case
  • Constants: SCREAMING_SNAKE_CASE
• Scope:
  • Checks top-level definitions (types, functions, values).
  • Checks let-bindings and pattern matches.
  • Checks function arguments (including in scattered definitions and implementation definitions).
• Documents: Update doc/asciidoc/usage.adoc to include usage instructions for the new flags and correct the strict mode flag name.

Relative Issue

Closes #1567

Implementation Details

The checks are implemented as an AST traversal in src/lib/naming_check.ml. The traversal ensures that:

1. Function arguments in standard definitions (FD_function) are checked.
2. Function arguments in scattered definitions (SD_funcl) are checked.
3. Function arguments in implementation definitions (DEF_impl) are checked.
4. Pattern matching bindings in let statements and match expressions are verified.

[Timmmm]

Nice work - I did start looking at this but from the lints.ml file - see my code here... but I didn't manage to get through the whole AST (wish it was better documented).

[bacam]

I think these should be checked as variant style, as with the members of enums.

[bacam]

We should treat operators differently to other identifiers here.

[bacam]

Thanks for working on this. I tried it out on the RISC-V model to get an idea of how well it's currently working, and there are some things we need to think about:

• It checks everything, including the standard library (which is particularly undisciplined at the moment). We could potentially do some filtering by filename or through the module system, or apply different styles to different parts.
• The checking is performed relatively late, which means that various generated identifiers are present.
• Perhaps autogenerated identifiers like undefined_<type> should follow the style in use.
• Type-level integers such as xlen should perhaps have their own style.
• Similarly, it's not clear to me whether let xlen = sizeof(xlen) should generate a warning or not.
• We use names with leading underscores for a couple of different purposes (e.g., unused arguments, or special internal functions)
• Instruction names in constructors tend to be treated differently to other names.
• Acronyms, type names, and domain-specific capitalisations often get embedded in names that are otherwise snake-case, e.g. f_is_NaN, read_CSR.
• Numerals appear frequently in floating point and vector function names.

[github-actions]

Test Results

   16 files     36 suites   0s ⏱️
1 013 tests 1 010 ✅  3 💤 0 ❌
4 906 runs  4 864 ✅ 42 💤 0 ❌

Results for commit 3754b24.

[Timmmm]

Perhaps it would be useful to add a smallish test case with all of the different usage styles @bacam discovered (e.g. let xlen = sizeof(xlen), read_CSR etc.