go vet

go vet is the analyser that ships with the Go toolchain. It runs a set of around forty analyzers from the go/analysis framework, such as printf and unusedresult, and it is the one Go check every project has whether or not it configured anything. Its significance for this method is the -vettool flag, which swaps in a different driver and so lets a project run analyzers of its own through the standard command.

How it is conformant

Bespoke rules are possible. The go command documents that “the -vettool=prog flag selects a different analysis tool with alternative or additional checks”, and the analysis framework provides singlechecker and multichecker to build such a tool from analyzers the project writes (4.1). The analysistest package runs one analyzer against a testdata directory and checks its diagnostics against // want comments, which is a purpose-built harness for the red proof (analysistest, 4.2). The analyzer Name is chosen once by its author and “must be a valid Go identifier as it may appear in command-line flags, URLs, and so on”, so it is stable and not derived from a path (4.3, in part). go vet runs locally, accepts the same package patterns as the rest of the go command, and prints findings in its own output (5.1, 5.2, 5.3); setting one analyzer flag such as -printf=true runs only that analyzer (5.4). go tool vet help <name> prints the analyzer’s Doc from the installed toolchain, so the bundled identifiers resolve offline and the documentation travels with the analyzer (6.1, 6.2, 6.3). Clause 7.1 holds by omission: go vet offers no inline suppression route at all, so there is nothing a project would need to disable or detect, and 7.2 has nothing to apply to.

How it is not conformant

Clause 4.3 is the one MUST not shown to hold. The human-readable output does not carry the analyzer name with each line in the documented format, and the vet documentation describes -json output without stating that the name is included, so the printing half of 4.3 is recorded as not verified for plain output. For a custom -vettool, help on the project’s own driver resolves its analyzers, which is the project’s driver rather than go vet and goes beyond what 6.1 asks of the detector. There is no rule over the rules under 4.4, although the framework requires a Doc on every analyzer, and no release gate over bundled documentation is documented (6.4, not verified). Readiness is 🟡 rather than 🟢 because the bespoke route requires building and installing a separate driver binary, and because the identifier is not verified as printed with plain-text findings.

Clause by clause

Notes for a practitioner

Write the class as a go/analysis analyzer, prove it with analysistest, and build it into a multichecker driver the project installs and invokes through go vet -vettool. Because there is no suppression route, any narrowing must live in the analyzer’s own code with its sentence in the Doc string, which is where go tool vet help will show it, and check the driver’s -json output for the analyzer name before relying on plain text.