x/tools/go/analysis/singlechecker: don't use flag.CommandLine

[mvdan]

Using package flag's global flagset is convenient, but shouldn't happen in packages like singlechecker and unitchecker which may be used in many different ways.

In particular, lots of packages like to abuse the same global flagset, such as testing and net/http/pprof, among many others outside the standard library.

Granted that a linter should generally not import those packages to begin with. But sometimes you just can't control your dependencies. And there's the case which I hit - I'm running my tool as part of a test, so testing is in the build import graph. So one of my tests is failing as the testing flags are getting mixed into the usage output.

I presume we could have unitchecker export a global flagset, and singlechecker could use it too.

[bcmills]

I'm running my tool as part of a test, so testing is in the build import graph.

Um... How does that follow? (Shouldn't the test exec the tool, the same as users will?)

(CC @ianthehat @alandonovan)

[mvdan]

Yes, the test uses exec to run the tool as a binary. But it doesn't require a separate binary to be somewhere on disk; instead, it adds some code in TestMain so that running the test binary with a certain env var will run that tool's main function instead of the tests.

I know this is a bit weird to try to summarize. Search for TestMain in https://godoc.org/github.com/rogpeppe/go-internal/testscript.

[alandonovan]

This seems like a variation on #30219. The single and multichecker packages are not designed to be used in this way. Please fork/exec a program for which they define the main function.

[mvdan]

Yes, it is quite similar. Feel free to close it as a duplicate. The reason I opened it separately is because not using flag.CommandLine is quite easy, and there's no apparent benefit to sticking to it.

[mvdan]

Seems like we're converging on adding a "cover" package in the standard library in the other thread; closing this one.