Skip to content
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

Consider supporting //nolint:nilaway in standalone mode #143

Closed
philipaconrad opened this issue Nov 29, 2023 · 3 comments
Closed

Consider supporting //nolint:nilaway in standalone mode #143

philipaconrad opened this issue Nov 29, 2023 · 3 comments
Labels
enhancement New feature or request

Comments

@philipaconrad
Copy link

Background

In PR #11, the original hard-coded //nolint:nilaway ignore directive support was removed. This change allowed Nilaway to more easily integrate with other linter/analysis drivers, but also removed the ability for standalone Nilaway to ignore spurious errors.

Waiting for other common linter drivers to integrate Nilaway may be futile-- see the consistently closed PRs and issues over in the golangci-lint repo, for instance. (The team there judged Nilaway to be too high a false positive rate for them to even consider integrating it as a supported linter. Using Nilaway as a plugin to golangci-lint is technically possible, but that style of integration is fairly unpleasant to implement and maintain, due to matching-version build requirements for both golangci-lint and the plugin.)

Note: Teams using the Bazel nogo integration may be able to use Nilaway a little-- I don't know anyone using Bazel for Golang development right now, so I can't comment on that integration.

Proposal

If the standalone Nilaway driver under cmd/nilaway could have support for ignore directives again in some form, this would allow many teams and projects to try out the linter while it's maturing-- they will be able to work around the current high false-positive rate, and bring the linter into CI use cases more easily.

@philipaconrad
Copy link
Author

I'll also note that I'm happy to take a stab at contributing back support for this feature if the team's okay with it. I'll take a look at what was removed in #11, and try to add back the essential bits, without b0rking the integration story outside of standalone mode.

ryancragun added a commit to hashicorp/enos that referenced this issue Nov 30, 2023
When testing scenario filters with negations for variants that didn't
exist for some scenarios, I ran into a panic in the Matrix implementation
due to not checking for nil and handling it appropriately in our
exclusions. After fixing it I decided to use the `nilaway`[0] static
analysis tool to verify the entire `flightplan` package.

The tool itself definitely has a few rough edges, and there were times
when it was confused and I had to do things more than once in a function
to please it, but overall it found several useful improvements.

It was fairly time consuming so I scoped this to just the `flightplan`
package for now. Eventually it might be nice to enable for the entire
program but we'd either need to architect away our use of global
variables for the UI, server client, and server, or we'd need them to
reintroduce per line `//nolint` directives[1].

It also has a few show stopper bugs like not being able to handle
listening on a nil channel in a select statement.[2] A tool with a
promising and useful future but needs more time for us to enforce.

[0] https://github.com/uber-go/nilaway
[1] uber-go/nilaway#126
[2] uber-go/nilaway#143

Signed-off-by: Ryan Cragun <[email protected]>
@jaredmorrow
Copy link

+1, right now many people can only run nilaway in standalone mode and removing //nolint:nilaway support makes that impossible with the many false positives.

ryancragun added a commit to hashicorp/enos that referenced this issue Dec 1, 2023
When testing scenario filters with negations for variants that didn't
exist for some scenarios, I ran into a panic in the Matrix implementation
due to not checking for nil and handling it appropriately in our
exclusions. After fixing it I decided to use the `nilaway`[0] static
analysis tool to verify the entire `flightplan` package.

The tool itself definitely has a few rough edges, and there were times
when it was confused and I had to do things more than once in a function
to please it, but overall it found several useful improvements.

It was fairly time consuming so I scoped this to just the `flightplan`
package for now. Eventually it might be nice to enable for the entire
program but we'd either need to architect away our use of global
variables for the UI, server client, and server, or we'd need them to
reintroduce per line `//nolint` directives[1].

It also has a few show stopper bugs like not being able to handle
listening on a nil channel in a select statement.[2] A tool with a
promising and useful future but needs more time for us to enforce.

[0] https://github.com/uber-go/nilaway
[1] uber-go/nilaway#126
[2] uber-go/nilaway#143

Signed-off-by: Ryan Cragun <[email protected]>
@yuxincs yuxincs added the enhancement New feature or request label Dec 6, 2023
@yuxincs
Copy link
Contributor

yuxincs commented Dec 6, 2023

Original we had support for this //nolint:nilaway only in file docstrings: if we detect such strings in the docstring of a particular file, the analysis for that particular file is skipped.

Please note that the original support deviates from the actual meaning of //nolint:nilaway, the consensus for such a comment means "still analyze what you have to, but suppress the errors made to the following block of code".

Therefore, in #11 we removed such support to avoid the confusions, and more importantly, relies on the driver to implement such features (which is the case for nogo, and I think for golangci-lint?). Unfortunately, this doesn't seem to be the case for the driver in go/analysis, which is what we are using for standalone NilAway. I'm curious to see if the importable driver that google go folks are brewing supports such thing golang/go#61324

Anyways, I still think that such responsibilities should be on the driver side: linters should just throw whatever errors it finds, and it's up to the driver to decide what to deal with suppressions.

But, unfortunately even with the standard go/analysis framework, the drivers do not still seem to have converged when it comes to handling suppressions. Plus, we have this cross-package nolint support problem (see #91) such that we may have to support it within NilAway for the time being. NilAway has entered many uncharted territories when it comes to cross-package program analysis for Go, interestingly, and perhaps unfortunately :)

Closing this as duplicated by #91

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants