Consider supporting `//nolint:nilaway` in standalone mode

[philipaconrad]

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]

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.

[jaredmorrow]

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

[yuxincs]

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