feat(lint): poc 2.0 linter gno handle extensions rules

[MikaelVallenet]

New Proposal for Linter Extension Rules

I did this first PR #4913 to implement linting warning on avl tree iterate method without limit. It was a "wild" PoC mixing preprocessing and linting logic.

This PR is an improved proposal with a lintrules interface and where each enabled implementations will run a function on all the nodes of the AST. (The AST traversal is done one time, but each node traversed applied the ruleset enabled)

The question is should i keep going in this way or do i go in the wrong direction ?

---

My next steps would be:

• Clean the code, improved the naming, the interface and implementations
• Allow in the CLI to enable/disable rules with a default preset

Small drawing of what i did

cc @moul @aeddi @thehowl

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• [ ] IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info) 🟢 Pending initial approval by a review team member, or review from tech-staff

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 The pull request was created from a fork (head branch repo: MikaelVallenet/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Pending initial approval by a review team member, or review from tech-staff

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 Not (🔴 Pull request author is a member of the team: tech-staff)

Then

🟢 Requirement satisfied
└── 🟢 If
    ├── 🟢 Condition
    │   └── 🟢 Or
    │       ├── 🔴 At least one of these user(s) reviewed the pull request: [jefft0 leohhhn n0izn0iz notJoon omarsy x1unix] (with state "APPROVED")
    │       ├── 🔴 At least 1 user(s) of the team tech-staff reviewed pull request
    │       └── 🟢 This pull request is a draft
    └── 🟢 Then
        └── 🟢 Not (🔴 This label is applied to pull request: review/triage-pending)

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[codecov[bot]]

Codecov Report

:x: Patch coverage is 44.79167% with 53 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
gnovm/cmd/gno/lintrules/avl-limit.go	16.27%	36 Missing :warning:
gnovm/cmd/gno/lint.go	81.81%	6 Missing and 2 partials :warning:
gnovm/pkg/gnolang/preprocess.go	0.00%	5 Missing :warning:
gnovm/pkg/gnolang/types.go	0.00%	4 Missing :warning:

:loudspeaker: Thoughts on this report? Let us know!

[aeddi]

Sounds like a good place to plug you in for the linter, but I’m not an expert at all, Morgan will have a much more informed opinion.

A few thoughts though:

• I think it makes more sense to put the .gno test files in a folder similar to gnovm/tests instead of in the examples folder, which is meant to be stored on-chain and callable.

• It might be useful to create a standard structure for each lint rule. For example, have a subfolder with the implementation plus docs/specs (Markdown? or JSON so it’s easier to parse, even by the lint tool itself). It could include an ID for the rule (similar to https://staticcheck.dev/docs/checks/), a short description, a longer description, and maybe a workaround with example code, etc.