Example of a comment to disable a check at one call-site?

[thockin]

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?

[quasilyte]

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.

[thockin]

Using it thru golangci-lint, I still don't see a way to //nolint a single ruleguard rule?

[mislav]

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.

[quasilyte]

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.

[mislav]

@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. golangci/golangci-lint#741

[quasilyte]

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).

[thockin]

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 <#248 (comment)>, 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> .

[quasilyte]

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.