-
Notifications
You must be signed in to change notification settings - Fork 404
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
base: master
Are you sure you want to change the base?
Conversation
@@ -112,6 +112,8 @@ const ( | |||
|
|||
type Name string | |||
|
|||
func (n Name) String() string { return string(n) } |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
🛠 PR Checks SummaryAll Automated Checks passed. ✅ Manual Checks (for Reviewers):
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) ☑️ Contributor Actions:
☑️ Reviewer Actions:
📚 Resources:Debug
|
@@ -0,0 +1,22 @@ | |||
# testing gno tool lint command: Render function with multiple cardinality errors (too many parameters and returns) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this 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
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? |
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 |
@@ -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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Codecov ReportAttention: Patch coverage is
📢 Thoughts on this report? Let us know! |
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. |
There was a problem hiding this 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 :)
There was a problem hiding this comment.
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 byparseCheckMemPackage
- This way we can use
pkg.Scope()
to find aRender()
function, if any, and then verify its signature. - The code in this file should be significantly shorter.
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
Issue
Render
func signature. #4026Description
lintRenderSignature
that asserts a public Render func follows the required signaturefunc Render(string) string)
testdata/lint
to assert the aboveTesting Validation
go test ./gnovm/cmd/gno/ -run Test_Scripts/lint