Bazel's nogo driver runs the Go analysis framework by executing a unitchecker-based command on each compilation unit.
I plan to change unitchecker so that it does its own type exporting. It already runs the type checker, so it's little extra work to export type information alongside facts. This means it will no longer rely on the Go compiler having produced type information, so go vet will be able to be substantially simplified. The change to unitchecker is https://go.dev/cl/824004.
Historically, Blaze [sic] treated std different from google3 packages, so its version of nogo was unable to run analysis on std packages. Consequently those packages lacked facts, which is why analyzers such as the printf checker included hardcoded lists of std functions (such as log.Printf) that are printf wrappers. However, Blaze has since evolved so that it now analyzes all packages uniformly. I plan to change Blaze in Google3 CL 974003901 so that it no longer skips std packages (with the immediate benefit that it derives std facts automatically).
When the unitchecker changes, it will no longer be acceptable to skip std packages, because unitchecker will assume that the .vetx files it produces and consumes contain both type and fact information, and it will no longer look at type information (.x) files produced by the compiler. (This work is part of the umbrella of golang/go#79427.) Therefore Bazel's nogo may need corresponding changes to ensure that it too executes the analyzers on all Go packages in the transitive closure, including std.
Bazel's nogo driver runs the Go analysis framework by executing a unitchecker-based command on each compilation unit.
I plan to change unitchecker so that it does its own type exporting. It already runs the type checker, so it's little extra work to export type information alongside facts. This means it will no longer rely on the Go compiler having produced type information, so
go vetwill be able to be substantially simplified. The change to unitchecker is https://go.dev/cl/824004.Historically, Blaze [sic] treated std different from google3 packages, so its version of nogo was unable to run analysis on std packages. Consequently those packages lacked facts, which is why analyzers such as the printf checker included hardcoded lists of std functions (such as log.Printf) that are printf wrappers. However, Blaze has since evolved so that it now analyzes all packages uniformly. I plan to change Blaze in Google3 CL 974003901 so that it no longer skips std packages (with the immediate benefit that it derives std facts automatically).
When the unitchecker changes, it will no longer be acceptable to skip std packages, because unitchecker will assume that the .vetx files it produces and consumes contain both type and fact information, and it will no longer look at type information (.x) files produced by the compiler. (This work is part of the umbrella of golang/go#79427.) Therefore Bazel's nogo may need corresponding changes to ensure that it too executes the analyzers on all Go packages in the transitive closure, including std.