feat(lint): poc avl tree usage limit

[MikaelVallenet]

It's a PoC for me
I would like to find how efficiently retrieve the comment just above the call to tree.Iterate or tree.ReverseIterate
fix #4421

[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]

Codecov Report

❌ Patch coverage is 30.61224% with 34 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
gnovm/pkg/gnolang/preprocess.go	11.42%	30 Missing and 1 partial ⚠️
gnovm/cmd/gno/lint.go	60.00%	2 Missing ⚠️
gnovm/pkg/test/imports.go	50.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[moul]

Thank you @MikaelVallenet. Before we move too far in this direction, I think it’s a good moment to discuss whether we want the official linter to start including this kind of specialized rule.

On one hand, I love the idea. One of the strengths of Go is that it provides strong built-in tooling (linter, tests, coverage, docs, formatter, etc). On the other hand, we may choose minimalism for the monorepo and keep extra lint rules as optional extensions. But in that case, optional linters tend to become either always expected or often forgotten, which creates inconsistency.

My personal vote is to allow this specialization, but I would like more people to give their input before we commit to a direction.

And just to be clear. I’m not talking about how it should be implemented yet. There’s a separate question about whether this belongs in the preprocessor as you did, in cmd/lint.go, or elsewhere. Before discussing implementation details, we first need to decide whether this monorepo should officially include more opinionated lint rules or not.

[aeddi]

I feel that for this kind of opinionated rules it would make sense to group them under a single 'official' linter and to document them in the monorepo (to explain why this rule exists, its technical implications, the best practices to fix or improve code that triggers it, etc.).

However, it could also be useful to have a system like golangci-lint that allows disabling specific non-critical rules or ignoring particular sections of code.

[moul]

We should have two rule layers:

1. A linter that provides warnings and allows package-specific rules (like the one proposed here). Since the rule set will likely grow over time, I suggest keeping the logic in a dedicated folder (lintrules/avl-limit.go), and gnovm/pkg/gnolang should not depend on it (cannot be located in the preprocessor as you did here).
2. A strict rule set enforced after(!) preprocessing. These are the “laws”. They act as a security-audit stage, with failures blocking execution. The linter would also remind developers of these mandatory rules (!= warnings).

Both lists should evolve over time.

In the future, we may also want the linter to be runnable by an oracle service, which could publish audit reports on-chain. Gnoweb could then display the latest rule-checks, even when the contract itself hasn’t changed.