bazel-contrib / bazel-contrib/rules_go

nogo: unitchecker will soon own type exporting; skipping std will not work

Open
#4,702 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
1.5k
Forks
760
Avg merge
1d 11h
Merged PRs (30d)
12

Description

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.

Contributor guide

Open the contributing guide

Research direction

Start by reading the nogo driver and the linked unitchecker change, focusing on how analyzers are run and how .vetx and compiler .x files are handled. Check the planned Bazel change for skipping standard-library packages; done means nogo runs analyzers on all Go packages in the transitive closure and remains compatible with unitchecker-owned type and fact information.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
build-system
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.