go-ruleguard
go-ruleguard copied to clipboard
quasilyte
Example of a comment to disable a check at one call-site?
Many/most linters have some sort of way to disable a specific check at a specific call-site. Are there examples on how to do this in ruleguard?
Hello!
ruleguard binary is not that well suited for the CI integration. It's mostly a tool that helps you to develop and debug the linting rules.
On the bright side, there is golangci-lint tool that embeds ruleguard (through gocritic linter). Here is an example of how you can enable it there: https://quasilyte.dev/blog/post/ruleguard/#using-from-the-golangci-lint
Note: golangci-lint will probably have some previous stable release available; so there is some update lag in there.
go-critic also does that: https://github.com/go-critic/go-critic/blob/master/.golangci.yml#L44
It could be possible to implement more user-oriented features in ruleguard itself, but if we look at the main file, it becomes apparent that we're trying to be as thin analysis-based tool as possible:
https://github.com/quasilyte/go-ruleguard/blob/master/cmd/ruleguard/main.go
There is a reason to do it this way.
ruleguard can be used as a library to build your own rule runners. For instance, go-critic embeds ruleguard as a library: https://github.com/go-critic/go-critic/blob/master/checkers/ruleguard_checker.go (without using the go-ruleguard/analyzer package).
If go/analysis provides some easy way to achieve that "ignore" behavior, maybe we can use that.
In case you're not using the golangci-lint or can't use it, I wonder if it's possible to use an external warnings filter.
Using it thru golangci-lint, I still don't see a way to //nolint a single ruleguard rule?
Through golangci-lint I've found that you can do //nolint:gocritic to disable ruleguard for a specific line, but of course, this disables all ruleguard reporting for that line. I did not find a way to disable only a specific ruleguard rule by name.
Furthermore, the nolintlint golangci-linter (which reports unused //nolint directives) sometimes complains that specific //nolint:gocritic directives were not used by gocritic, even if said line would fail without the directive. Such false positives would go away after golangci-lint cache clean.
Does golangci-lint have any linters that can have a special comment like //nolint:lintername diagnostic-name?
If it does, it should be possible to add //nolint:gocritic ruleguard/something.
@quasilyte I don't think so. golangci-lint only supports //nolint:<linter> // <description> statements, where description is meant to be human-readable and can't specify rules to disable, to my knowledge. https://github.com/golangci/golangci-lint/issues/741
Maybe we need to take a look at the specific rules then and try to make them smarter, so they have fewer false positives.
Although I agree that it's unfortunate that we can't get this behavior via nolint directives.
CC @ernado what do you think about additional nolint syntax? //nolint:<linter>:<diag>
It would be useful for multi-diagnostics linters like staticcheck and gocritic.
For ruleguard, I think it could be //nolint:gocritic:ruleguard/rule_name (using the same format, but with / to handle the namespacing). In theory, it's possible to register rules as first-class diagnostics, so it becomes //nolint:gocritic:rule_name. Note that we already do that with embedded ruleguard rules inside gocritic (we're registering them as normal checkers).
The downside of a metalinter wrapping a metalinter wrapping a bunch of linters. I'd prefer to see ruleguard and other granular linters directly in golangci-lint (which seems bound to be the "winner") rather than go-critc and other intermediate layers.
On Mon, Aug 16, 2021 at 3:56 AM Iskander (Alex) Sharipov < @.***> wrote:
Maybe we need to take a look at the specific rules then and try to make them smarter, so they have fewer false positives.
Although I agree that it's unfortunate that we can't get this behavior via nolint directives.
CC @ernado https://github.com/ernado
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/quasilyte/go-ruleguard/issues/248#issuecomment-899416768, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKWAVE2BNJW4O4B5LRBNM3T5DVFHANCNFSM475P73FA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
I can see the point, but we'll still need something like //nolint:ruleguard:<rule_name> if we want to have a granularity of a single named rule.