mirror of
https://github.com/golang/go
synced 2024-11-19 21:34:45 -07:00
0d18875252
This CL adds an automatic, limited "go vet" to "go test". If the building of a test package fails, vet is not run. If vet fails, the test is not run. The goal is that users don't notice vet as part of the "go test" process at all, until vet speaks up and says something important. This should help users find real problems in their code faster (vet can just point to them instead of needing to debug a test failure) and expands the scope of what kinds of things vet can help with. The "go vet" runs in parallel with the linking of the test binary, so for incremental builds it typically does not slow the overall "go test" at all: there's spare machine capacity during the link. all.bash has less spare machine capacity. This CL increases the time for all.bash on my laptop from 4m41s to 4m48s (+2.5%) To opt out for a given run, use "go test -vet=off". The vet checks used during "go test" are a subset of the full set, restricted to ones that are 100% correct and therefore acceptable to make mandatory. In this CL, that set is atomic, bool, buildtags, nilfunc, and printf. Including printf is debatable, but I want to include it for now and find out what needs to be scaled back. (It already found one real problem in package os's tests that previous go vet os had not turned up.) Now that we can rely on type information it may be that printf should make its function-name-based heuristic less aggressive and have a whitelist of known print/printf functions. Determining the exact set for Go 1.10 is #18085. Running vet also means that programs now have to type-check with both cmd/compile and go/types in order to pass "go test". We don't start vet until cmd/compile has built the test package, so normally the added go/types check doesn't find anything. However, there is at least one instance where go/types is more precise than cmd/compile: declared and not used errors involving variables captured into closures. This CL includes a printf fix to os/os_test.go and many declared and not used fixes in the race detector tests. Fixes #18084. Change-Id: I353e00b9d1f9fec540c7557db5653e7501f5e1c9 Reviewed-on: https://go-review.googlesource.com/74356 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org> |
||
---|---|---|
.. | ||
all | ||
internal | ||
testdata | ||
asmdecl.go | ||
assign.go | ||
atomic.go | ||
bool.go | ||
buildtag.go | ||
cgo.go | ||
composite.go | ||
copylock.go | ||
dead.go | ||
deadcode.go | ||
doc.go | ||
httpresponse.go | ||
lostcancel.go | ||
main.go | ||
method.go | ||
nilfunc.go | ||
print.go | ||
rangeloop.go | ||
README | ||
shadow.go | ||
shift.go | ||
structtag.go | ||
tests.go | ||
types.go | ||
unsafeptr.go | ||
unused.go | ||
vet_test.go |
Vet is a tool that checks correctness of Go programs. It runs a suite of tests, each tailored to check for a particular class of errors. Examples include incorrect Printf format verbs and malformed build tags. Over time many checks have been added to vet's suite, but many more have been rejected as not appropriate for the tool. The criteria applied when selecting which checks to add are: Correctness: Vet's checks are about correctness, not style. A vet check must identify real or potential bugs that could cause incorrect compilation or execution. A check that only identifies stylistic points or alternative correct approaches to a situation is not acceptable. Frequency: Vet is run every day by many programmers, often as part of every compilation or submission. The cost in execution time is considerable, especially in aggregate, so checks must be likely enough to find real problems that they are worth the overhead of the added check. A new check that finds only a handful of problems across all existing programs, even if the problem is significant, is not worth adding to the suite everyone runs daily. Precision: Most of vet's checks are heuristic and can generate both false positives (flagging correct programs) and false negatives (not flagging incorrect ones). The rate of both these failures must be very small. A check that is too noisy will be ignored by the programmer overwhelmed by the output; a check that misses too many of the cases it's looking for will give a false sense of security. Neither is acceptable. A vet check must be accurate enough that everything it reports is worth examining, and complete enough to encourage real confidence.