Skip to content

feat(gnolint): add lint checks for Render #4083

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

itsHabib
Copy link

@itsHabib itsHabib commented Apr 9, 2025

Issue

Description

  • Adds a func lintRenderSignature that asserts a public Render func follows the required signature func Render(string) string)
  • Adds test files in testdata/lint to assert the above

Testing Validation

  • go test ./gnovm/cmd/gno/ -run Test_Scripts/lint
    test-lint

@@ -112,6 +112,8 @@ const (

type Name string

func (n Name) String() string { return string(n) }
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

happy to remove this change if its adding unnecessary changes to the PR

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it's not really necessary anyway

@Gno2D2 Gno2D2 requested a review from a team April 9, 2025 05:33
@Gno2D2
Copy link
Collaborator

Gno2D2 commented Apr 9, 2025

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):
  • IGNORE the bot requirements for this PR (force green CI check)
  • The pull request description provides enough details
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:
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: itsHabib/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 1 user(s) of the organization reviewed the pull request (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
The pull request description provides enough details

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 Not (🔴 Pull request author is a member of the team: core-contributors)
    └── 🟢 Not (🔴 Pull request author is user: dependabot[bot])

Can be checked by

  • team core-contributors

@itsHabib itsHabib marked this pull request as ready for review April 9, 2025 05:35
@Gno2D2 Gno2D2 added the review/triage-pending PRs opened by external contributors that are waiting for the 1st review label Apr 9, 2025
@@ -0,0 +1,22 @@
# testing gno tool lint command: Render function with multiple cardinality errors (too many parameters and returns)
Copy link
Author

@itsHabib itsHabib Apr 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to either have all these tests in a single file or have a testdata/lint/render but figured this is fine for now and can be done in a separate PR if thats needed to keep this one focused. I wasn't sure how to do the former(if its supported) and the latter isn't supported currently

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say to have these as unit tests in tool_lint_test.go; they're definitely too "table-like" to have as integration tests.

Copy link
Member

@notJoon notJoon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

remove: review/triage-pending flag

@notJoon notJoon removed the review/triage-pending PRs opened by external contributors that are waiting for the 1st review label Apr 9, 2025
@itsHabib
Copy link
Author

itsHabib commented Apr 9, 2025

appreciate the review @notJoon, should i be expected to merge now? seems like its still pending a review from tech-staff but i noticed the label is now removed, is that expected?

@leohhhn leohhhn requested review from thehowl and mvertes and removed request for a team April 9, 2025 15:28
@itsHabib
Copy link
Author

itsHabib commented Apr 9, 2025

I see i broke some test. I will see what i can do to fix

Update: found the problem, the panic occurs due to me using MustParseFile. might just be better to return early/continue since cant lint a render if the file itself cant be parsed

@@ -171,6 +172,11 @@ func execLint(cfg *lintCfg, args []string, io commands.IO) error {
if hasRuntimeErr {
hasError = true
}

// ensure Render function signature matches what's expected
if renderErr := lintRenderSignature(io, memPkg); renderErr {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question for reviewers: should the lint render be called only if the above runtime err is false? or could there still be value in it as maybe some file could still have a Render that can be checked?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better to continue the lint check regardless of whether a runtime error occurs.

Copy link

codecov bot commented Apr 9, 2025

Codecov Report

Attention: Patch coverage is 97.26027% with 2 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
gnovm/cmd/gno/tool_lint.go 97.22% 1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

@notJoon
Copy link
Member

notJoon commented Apr 10, 2025

should i be expected to merge now? seems like its still pending a review from tech-staff but i noticed the label is now removed, is that expected?

@itsHabib

actually not right now. the first round of reviews is over, so I think it will be take another time to being merge this PR.

Copy link
Member

@thehowl thehowl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your contribution! I think we can do better, as to avoid an additional parsing round in the VM, by re-using the information we already get from the Go type checker :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can do better; the code is not really adapted to easily allow for more code-level lints, but I think we can adapt it easily:

  • TypeCheckMemPackage should be able to return the *types.Package returned by parseCheckMemPackage
  • This way we can use pkg.Scope() to find a Render() function, if any, and then verify its signature.
  • The code in this file should be significantly shorter.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @thehowl! i will get to it when i can

@@ -0,0 +1,22 @@
# testing gno tool lint command: Render function with multiple cardinality errors (too many parameters and returns)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say to have these as unit tests in tool_lint_test.go; they're definitely too "table-like" to have as integration tests.

@Kouteki Kouteki moved this from Triage to In Review in 🧙‍♂️gno.land core team Apr 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📦 🤖 gnovm Issues or PRs gnovm related
Projects
Status: In Progress
Status: In Review
Development

Successfully merging this pull request may close these issues.

gno lint: check Render func signature.
4 participants