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
Implement a checker for the golang staticcheck
tool
#1541
Conversation
This commit adds the `staticcheck` tool to this Docker image, for testing the new [`go-staticcheck`](flycheck/flycheck#1541) linter.
Hey, sorry for the delay. This is a very nice PR, thank you. I'll try to review it soon enough. |
LGTM, but you will need to clear the CI before we can merge. Currently it's failing on formatting errors in |
Great work, @Gastove! Any chance of fixing the formatting errors and getting this merged soon? |
Hello! Apologies -- Life happened. Back now! Will get this cleaned up quick as I can |
This commit implements `go-staticcheck`, a checker wrapping the `staticcheck` tool. `staticcheck` is the successor to `megacheck`, which is now deprecated. This commit includes: 1. A checker definition for `go-staticcheck`. 2. The introduction of a new variable, `flycheck-go-version`, which can be passed to `staticcheck` to specify the version of the Go compiler to perform checks compatible with. 3. A test for `staticcheck`. 4. Updates to appropriate documentation. 5. Updates to other Golang syntax checkers to prefer falling back to `staticcheck` before `megacheck`. The documentation pass includes: 1. `rst` docs for `go-staticcheck` itself. 2. An update to the documentation for `megacheck`, specifying that it's deprecated. 3. Documentation for the new `flycheck-go-version` variable. 4. Updating the definition of `flycheck-go-build-tags` to correctly declare the full list of checkers that can use it.
This commit changes several things: 1. Based on PR feedback from @fmdkdd, don't force `staticcheck` to run in the local directory -- it's fine, but unnecessary. 2. Switch to using `staticcheck`'s JSON output; add a parser for it. This allows parsing error severity, which is excellent. 3. Add a buttercup test for `flycheck-parse-go-staticcheck`, and update the `staticcheck` integration test to correctly reflect new error parsing.
Hokay. Now passing format and checkdoc; the buttercup tests are passing as well. If I'm reading the (pretty extensive) CI output correctly, I'm currently failing the integration tests. Let me see what I can do about that. |
…k, build tests I'm trying to fix errors in CI I can't reproduce locally. My current hypothesis is that megacheck is stomping on staticcheck, and staticcheck is harming both megacheck and go-build.
Okay. I'm down to one last failing test. I'm.... pretty baffled by the error I'm getting, however. Can anyone advise? @fmdkdd? The error originates on line 3436 of (flycheck-ert-def-checker-test go-staticcheck go nil
:tags '(language-go external-tool)
(let ((flycheck-disabled-checkers '(go-golint go-megacheck)))
(flycheck-ert-with-env
`(("GOPATH" . ,(flycheck-ert-resource-filename "language/go")))
(flycheck-ert-should-syntax-check
"language/go/src/staticcheck/staticcheck1.go" 'go-mode
'(8 6 error "should omit values from range; this loop is equivalent to `for range ...`"
:checker go-staticcheck :id "S1005")
'(12 21 error "calling strings.Replace with n == 0 will return no results, did you mean -1?"
:checker go-staticcheck :id "SA1018")
'(16 6 error "func unused is unused"
:checker go-staticcheck :id "U1000"))))) The error from Test flycheck-define-checker/go-staticcheck/default condition:
(ert-test-failed
((should
(equal
(mapcar #'flycheck-error-without-group expected)
(mapcar #'flycheck-error-without-group flycheck-current-errors)))
:form
(equal
(#s(flycheck-error #<killed buffer> go-staticcheck "/flycheck/test/resources/language/go/src/staticcheck/staticcheck1.go" 8 6 "should omit values from range; this loop is equivalent to `for range ...`" error "S1005" nil)
#s(flycheck-error #<killed buffer> go-staticcheck "/flycheck/test/resources/language/go/src/staticcheck/staticcheck1.go" 12 21 "calling strings.Replace with n == 0 will return no results, did you mean -1?" error "SA1018" nil)
#s(flycheck-error #<killed buffer> go-staticcheck "/flycheck/test/resources/language/go/src/staticcheck/staticcheck1.go" 16 6 "func unused is unused" error "U1000" nil))
nil)
:value nil :explanation
(different-types
(#s(flycheck-error #<killed buffer> go-staticcheck "/flycheck/test/resources/language/go/src/staticcheck/staticcheck1.go" 8 6 "should omit values from range; this loop is equivalent to `for range ...`" error "S1005" nil)
#s(flycheck-error #<killed buffer> go-staticcheck "/flycheck/test/resources/language/go/src/staticcheck/staticcheck1.go" 12 21 "calling strings.Replace with n == 0 will return no results, did you mean -1?" error "SA1018" nil)
#s(flycheck-error #<killed buffer> go-staticcheck "/flycheck/test/resources/language/go/src/staticcheck/staticcheck1.go" 16 6 "func unused is unused" error "U1000" nil))
nil))) Can anyone advise? It reads like ert is trying to compare the three forms provided (all correctly of type |
If I read this correctly, |
@cpitclaudel aaaahaha. Yes, okay -- that does, at least, help with the interpretation of the error message. However, if I load the checker, then the test files, I am seeing the expected triplet of errors. So. Just have to figure out why no errors are being parsed by the integration test. |
Okay, I'm... a bit lost. If I don't disable |
THERE. Okay: for reasons I do not understand, disabling |
|
(I should have requested a squash — or performed it myself — sorry for the commit history noise @fmdkdd !) |
@cpitclaudel Arguably, the only benefit of squashing is when using @Gastove Adding a new checker to a chain will usually have effects on other checker tests, as you figured out. I wish the test output would make that explicit, but the thing to remember is that tests are meant to mimic the behavior of Flycheck from a user standpoint: when you open a file, the first valid checker is selected, then its Anyway, thanks for pulling through on this PR! |
@fmdkdd oh yes! I quite like I can make a to-do for myself to be sure that behaviour isn't present for users, submit any follow-up work in a new PR. Given that |
If megacheck has been deprecated and superseded, we should just drop it altogether. Users who wish to use the checker may still copy its definition to their own config. If you have time for this, please do open a PR. |
Works for me. I'll open an issue, just so I don't lose track of it; I should have time this weekend |
Commit Message:
This commit implements
go-staticcheck
, a checker wrapping thestaticcheck
tool.
staticcheck
is the successor tomegacheck
, which is nowdeprecated.
This commit includes:
go-staticcheck
.flycheck-go-version
, which can bepassed to
staticcheck
to specify the version of the Go compiler to performchecks compatible with.
staticcheck
.staticcheck
beforemegacheck
.The documentation pass includes:
rst
docs forgo-staticcheck
itself.megacheck
, specifying that it'sdeprecated.
flycheck-go-version
variable.flycheck-go-build-tags
to correctly declare thefull list of checkers that can use it.
A Note about this PR
So! Went to get this tested, and in doing so, discovered a few things. While the specs all pass on my local machine, the integration tests for go... do not. This is because the tests for Go tooling are hardcoded with the
go
binary installed in/usr/local/bin
; on Fedora, at least,go
is installed in/usr/bin
, so those tests fail as well.I'm currently testing changes to the all-tools Dockerfile; I'll make sure that PR is linked to this one once I've got everything together. My worldview here is that this means the tests on this PR wont pass until my PR is merged in to
docker-tools
, which is fine.I'll look in to updating the tests to more flexibly find the
go
binary if I have time!Thanks for a great tool, y'all, and my complements on superb contributor docs!