Add a vet pass that checks that the second argument to errors.As
is a pointer to a type implementing error.
Change-Id: I0924e634cbea0664c8728f0e74213b924f8498e6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/168938
Reviewed-by: Damien Neil <dneil@google.com>
Only warn if the method is missing for all types.
Fixesgolang/go#30971
Change-Id: I94169ad3266f68ca20378a8dc5538aed2541a773
Reviewed-on: https://go-review.googlesource.com/c/tools/+/168803
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Alternative build systems like blaze don't always provide a way to determine
the relationship between a package and the package it's testing. This means
that sometimes the check for misspelled Example function names over-reports
because it doesn't find the object being exemplified. Don't report errors
unless a object can't be found in any of the imports. This means that there
won't be any false positives though of course this comes at the cost of
false positives.
Change-Id: I7435eeb2333b6dd72e06bb6383fff2ac17bee845
Reviewed-on: https://go-review.googlesource.com/c/tools/+/168404
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Historically, vet had always been unhappy about encoding/xml itself:
method MarshalXML(e *xml.Encoder, start xml.StartElement) error should
have signature MarshalXML(*xml.Encoder, xml.StartElement) error
This dates back to the time when vet couldn't depend on type
information. It compared the type expressions directly as strings, which
was a problem when the code was in encoding/xml itself. There, the
function parameters are *Encoder and StartElement, not *xml.Encoder and
xml.StartElement.
However, vet has been depending on type information for a while, so this
restriction no longer makes sense. The analyzer almost got it right, but
the only stopgap was a piece of the old code that tried to compare type
expression strings.
Remove it; typeString already deals with these edge cases for us. To
ensure vet remains happy with encoding/xml, add a very simple test for
it. The package now has zero reports, so the fact that its source has
zero "// want" comments is appropriate.
Finally, remove some long unused parameters from matchParamType.
Change-Id: Iab3ed57da7bc4a80522ae21e62b67e7828b97c89
Reviewed-on: https://go-review.googlesource.com/c/tools/+/168058
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
It's possible to use a type which implements fmt.Formatter without
importing fmt directly, if the type is imported from another package
such as math/big.
On top of that, it's possible to use printf-like functions without
importing fmt directly, such as using testing.T.Logf.
These two scenarios combined can lead to the printf check not finding
the fmt.Formatter type, since it's not a direct dependency of the root
package.
fmt must still be in the import graph somewhere, so we could search for
it via types.Package.Imports. However, at that point it's simpler to
just look for the Format method manually via go/types.
Fixes#30399.
Change-Id: Id78454bb6a51b3c5e1bcb1984a7fbfb4a29a5be0
Reviewed-on: https://go-review.googlesource.com/c/163817
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
The new error value proposal (https://golang.org/design/29934-error-values)
adds stack frame information to the errors produced by errors.New
and fmt.Errorf. This will break any test that compares errors
with reflect.DeepEqual.
This vet check finds any call to reflect.DeepEqual both of whose
arguments are of type error, or are of a type that can store
of value of type error.
Change-Id: I55939339344ed5b4f61557a7296734a710211918
Reviewed-on: https://go-review.googlesource.com/c/162939
Reviewed-by: Damien Neil <dneil@google.com>
The atomicalign checker detects non-64-bit aligned struct field
arguments to sync/atomic functions but currently misses out cases
where the struct variable identifier is a pointer to struct. This
is very common as it happens when the 64-bit field is accessed
in a method with pointer receiver, where the struct is itself the
method receiver. Add some tests to cover that new case.
While I'm at it, fix some typos.
Change-Id: I582cf5b7286b11285010f085045f58dc636ef3ee
Reviewed-on: https://go-review.googlesource.com/c/158999
Reviewed-by: Alan Donovan <adonovan@google.com>
The atomicalign Analyzer checks the alignment of 64-bits variables
accessed atomically via sync/atomic functions on 32-bits
architectures. Per the sync/atomic BUG note those variables must
be 64-bits aligned, otherwise a runtime panic is issued.
The analyzer only shows and runs on 32-bits architectures.
This CL should not introduce any false positives.
Add some tests in testdata/src/a to verify the analyzer behavior
on affected architectures plus some very basic test to verify that
no warning is generated on non-affected ones.
Fixesgolang/go#11891
Change-Id: I02cfc574883564cd2a213a92d33bda3cc9a1ea98
Reviewed-on: https://go-review.googlesource.com/c/158277
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Many Analyzers need to measure the width of an integer and all today
use hacks. This change causes analysis.Pass to retain and expose the
type sizing function used during type checking.
This in turn requires go/packages to retain and expose the type sizing
function in Packages.TypesSizes, which addresses a longstanding need
among many of its clients.
Change-Id: Ia8362019bcde34c10cb4fbc38cfdfddcbef3eb5c
Reviewed-on: https://go-review.googlesource.com/c/158317
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Now that we support checking for duplicate struct field tags across
anonymous struct fields, we must deal with the fact that the files
involved in such a warning may not be in the same package or directory.
This could lead to errors where a file was mentioned in a package where
it didn't exist. Or even worse, point at a location within an existing
file that doesn't contain the field we want, causing even further
confusion to the user.
To fix this, always make the "also at" positions relative to the current
warning, if possible.
Fixes#29130.
Change-Id: Iaa29b406978f1671bdfb2ddddb7058eeffec92a9
Reviewed-on: https://go-review.googlesource.com/c/155899
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Array offsets in recursive structures do not include the accumulated
offset. This diff fixes the mistake and adds a test.
Fixesgolang/go#29318
Change-Id: Iaa2a2f9404e4ed0e38b87e5e041709c1a8e25809
Reviewed-on: https://go-review.googlesource.com/c/154665
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
The first issue is that %b and %o can print pointers, but printVerbs
didn't reflect that:
The %b, %d, %o, %x and %X verbs also work with pointers,
formatting the value exactly as if it were an integer.
The second issue is that arrays can never be printed as pointers. This
was previously reported as part of #27672.
The third issue is that only %p can print all slices, maps, and
functions as if they were pointers. This differs from verbs like %b or
%o, which can't print these types as pointers.
Fix all of the issues above, and add extensive test cases covering all
the combinations. Verified all of them with an executed program. The
amount of test cases is perhaps overkill, but this is not the first time
we've gotten the printf pointer logic wrong.
Updates #27672.
Fixes#28858.
Change-Id: I62eb79d505fd1e250a16b90bda3c68b702f35a29
Reviewed-on: https://go-review.googlesource.com/c/149979
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
As Alan rightfully guessed, porting the stdmethods check to use go/types
required the use of types.TypeString not only when printing signatures
in warnings, but also when matching them.
Added a simple test case too.
Fixesgolang/go#28792.
Change-Id: Ifbbdd4b1a2f1090d6f9a1674d52b8f0887a67d06
Reviewed-on: https://go-review.googlesource.com/c/149977
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
All of these were quite heavily indented for no good reason; breaking or
returning early makes the code easier to read and follow.
Change-Id: Ic539517b07604d71495277b16f1b7eb60d2e3d3c
Reviewed-on: https://go-review.googlesource.com/c/149978
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
The recursive stringer check should report cases such as
func (x T) String() string { return fmt.Sprint(x) }
in which the receiver x (or possibly &x) was passed into a fmt print call.
However, in translating it from the go/ast to the go/types representation,
I inadvertently made it report any situation in which a value of type T
was passed to fmt, even when the value is not x, as in:
func (cons *cons) String() string {
... fmt.Sprint(cons.cdr) ...
}
Fixed and tested.
Change-Id: I57e88755c9989deaaad45cc306a604f3db4ee269
Reviewed-on: https://go-review.googlesource.com/c/149616
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Type.String prints named types using the complete package path: "dir/pkg.T"
The notation used by canonicalMethod, and the cmd/vet/all whitelist,
and the one users want to see, uses only the package name: "pkg.T".
Change-Id: If2334a8cca1fb80e947cb105530b946a5a8dec7b
Reviewed-on: https://go-review.googlesource.com/c/149597
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Michael Matloob <matloob@golang.org>
Vet issues a warning (non-error diagnostic) when, for example, it
cannot check an assembly file because the Go and asm symbols are in
different packages. The new analysis API has no concept of warnings:
any diagnostic always causes a non-zero exit.
This change turns the asmdecl diagnostics back into warnings using
log.Print, which is not ideal, but is necessary to pacify cmd/vet/all
and its whitelist during the transition. Better solutions would be for
the new analysis API to have a concept of warning, or for asmdecl to
be silent and cmd/vet/all's whitelist not to expect these messages.
Also, fix a bug in the "cross-check" predicate: cmd/vet confuses the
name of a package and its path. The a∕b∕c names (using Unicode
division slash) that appear in assembly correspond directly to the
path.
The only effective test of this change will be cmd/vet/all itself.
Change-Id: I2e402d48717df723e2efdc2379636ec9b204031d
Reviewed-on: https://go-review.googlesource.com/c/149598
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Michael Matloob <matloob@golang.org>
Now that vet can rely on go/types, there's no reason to do extra work to
avoid using it. The rewrite lets us get rid of the field list flattening
code, as well as the slight verbosity that comes with go/printer.
While at it, make the testdata/method.go expected errors be more
specific, to make sure that we're not breaking the warnings that are
printed.
This change was originally made to cmd/vet in
https://go-review.googlesource.com/c/148919
Change-Id: I123e64d369e521199712c9807583c53d428534ac
Reviewed-on: https://go-review.googlesource.com/c/149418
Reviewed-by: Michael Matloob <matloob@golang.org>
Pointers to compound objects (structs, slices, arrays, maps) are only
followed by fmt if the pointer is at the top level of an argument. This
is to minimise the chances of fmt running into loops.
However, vet did not follow this rule. It likely doesn't help that fmt
does not document that restriction well, which is being tracked in
#28625.
This change was originally made to cmd/vet as
https://go-review.googlesource.com/c/147997.
Updates #27672.
Change-Id: I65944cf355baedb4578af57046e2bbfd3fe6a9dc
Reviewed-on: https://go-review.googlesource.com/c/149319
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
fmt's godoc reads:
For compound objects, the elements are printed using these
rules, recursively, laid out like this:
struct: {field0 field1 ...}
array, slice: [elem0 elem1 ...]
maps: map[key1:value1 key2:value2 ...]
pointer to above: &{}, &[], &map[]
That is, a pointer to a struct, array, slice, or map, can be correctly
printed by fmt if the type pointed to can be printed without issues.
vet was only following this rule for pointers to structs, omitting
arrays, slices, and maps. Fix that, and add tests for all the
combinations.
This change was originally made to cmd/vet in
https://go-review.googlesource.com/c/147758
Updates #27672.
Change-Id: I7e25ecaeed619ae8b6ada79bccacba6b67171733
Reviewed-on: https://go-review.googlesource.com/c/149318
Reviewed-by: Michael Matloob <matloob@golang.org>
This change adds to the list of standard library functions known to be
print or printf wrappers.
Although the printf Analyzer is capable of identifying wrapper
functions in the standard library, some drivers (e.g. Bazel) do not
apply analyzers to the standard packages. Really this is a bug
in those drivers but it is not likely to be fixed for a while.
Change-Id: I2032d0cb5fcb50e7b9933a75809becdd680380ec
Reviewed-on: https://go-review.googlesource.com/c/148572
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
When main.main returns, the process exits, so there's no need to cancel contexts.
This CL was originally reviewed as
https://go-review.googlesource.com/c/go/+/106915
and then retried in
https://go-review.googlesource.com/c/go/+/148758
but then reverted due to an embarrassing sequence
of careless moves.
Change-Id: Icdee0650996a442023e030697f10d2c31fd5fdff
Reviewed-on: https://go-review.googlesource.com/c/148877
Run-TryBot: Alan Donovan <adonovan@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
In vet, the shadow check is experimental, meaning not on by default.
The new analysis API has no concept of experimental, but you can
easily supply a different checker. By providing a shadow command, we
make it easy for users that want it to run it:
$ go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow
$ go vet -vettool $(which shadow) my/project
Change-Id: I25dc7f3c830296121c7217e4615e8ff90e1b7c79
Reviewed-on: https://go-review.googlesource.com/c/148565
Reviewed-by: Michael Matloob <matloob@golang.org>
The cgocall analyzer was originally written in vet to analyze "raw" cgo files,
which are type-checked on a best-effort basis. However, the go/analysis
API presents analyzers with "cooked" cgo files, which are well-typed
legal Go but obscure the relationship between a call C.f(...) and its arguments.
Prior to this CL, cgocall attempted to "uncook" the file, which was
as predictably fragile as it sounds, and it rapidly broke as the cgo
recipe evolved.
This change causes cgocall to parse, modify, type-check and analyze "raw"
cgo files. The approach (based on dot-importing the "cooked" package)
is rather too clever but should be more robust than the one it replaces.
Fixesgolang/go#28566
Change-Id: I3092a313c64d27153eaaa115fe8635abfed17023
Reviewed-on: https://go-review.googlesource.com/c/147317
Reviewed-by: Michael Matloob <matloob@golang.org>
The test correctly identified a problem.
Suppressing test to keep dashboard cleean, pending a fix.
Updates golang/go#28566
Change-Id: Ib3a8dbdd617c9f5701b5d6673434917d284dfb32
Reviewed-on: https://go-review.googlesource.com/c/147199
Run-TryBot: Alan Donovan <adonovan@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Also:
- add cmd/vet-lite, a version of cmd/vet that doesn't depend on
go/packages and must be run under "go vet". This will be vendored
into $GOROOT/src/cmd/vet.
- add an integration test for a unitchecker-based command under "go vet".
Change-Id: Id613dac2812816c6d6372fa6d1536c8d4e4c2676
Reviewed-on: https://go-review.googlesource.com/c/143418
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
The default value of -findcall.name has been changed to ""
to avoid producing noise.
Change-Id: I71554080bcc7b6e23f632b49e30590fa0b0bc034
Reviewed-on: https://go-review.googlesource.com/c/143297
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
All the passes have been moved into their own packages.
The README file has been saved for the new cmd/analyze command,
which will shortly be renamed to vet.
Change-Id: I68c765a4da2f8d5a2b0161b462bd81483b5ceed5
Reviewed-on: https://go-review.googlesource.com/c/143301
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Due to a bug in go/types, a function f(...T) has no type
recorded for the parameter type expression ...T, and apparently
this has never occcured in a file checked by asmdecl before.
The addParams function should really be simplified to use types.Signature.
Updates golang/go#28277
Change-Id: I5b73535a7739b6771ffef1c0a7568f5161d564d5
Reviewed-on: https://go-review.googlesource.com/c/143298
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
vet's "divergent" testdata package exercises various mistakes
in naming Example functions.
vet's "incomplete" testdata package has been deleted because
it is no longer applicable. It was intended to ensure that a
x_test.go file specified on its own would not trigger false
positives without the corresponding x.go files, but the
new Analysis API always analysis complete packages.
Change-Id: I1a40ead340c806b571302fdaa537f481514b0c22
Reviewed-on: https://go-review.googlesource.com/c/143300
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
This check uses the control-flow graph and SSA value graph to detect
problems such as:
p := &v
...
if p != nil { // tautological condition
}
and:
if p == nil {
print(*p) // nil dereference
}
(It was originally developed within Google's Go analysis framework and
can now be published in a form useful to all analysis drivers.)
This CL also includes buildssa, an Analyzer that constructs SSA for
later analysis passes but does not report diagnostics or facts of its
own.
Change-Id: I27bc4eea10d71d958685a403234879112c21f433
Reviewed-on: https://go-review.googlesource.com/c/142698
Reviewed-by: Michael Matloob <matloob@golang.org>
These structs appear in test main files generated by "go test"
and so can be trusted.
Change-Id: I1514a8cdcbd633392ccaaedfa8eccf944d514129
Reviewed-on: https://go-review.googlesource.com/c/142699
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
...and other trivial cleanups.
Multi-line doc comments have been moved to exported Doc constants for
the sake of godoc.
Change-Id: Ib1cbec5806c699d51283c34685c4cd96953f5384
Reviewed-on: https://go-review.googlesource.com/c/142360
Reviewed-by: Michael Matloob <matloob@golang.org>
Guide to changes:
- The -printfuncs flag is renamed -printf.funcs.
It no longer supports "pkg.T.f" form, requiring instead
"(dir/pkg.T).f" or "(*dir/pkg.T).f".
The legacy ":%d" suffix is no longer supported.
- (*testing.T).Errorf and friends are removed from the isPrint map
because they are discovered by induction while analyzing package
"testing".
- localPrintfLike map operations are replaced by the Fact mechanism.
- The go/types representation is used instead of strings/ast.Nodes in
various places. For example:
pkgpath, name string -> *types.Func (to identify a function)
format, args *ast.Field -> *types.Var (to identify format/args params)
This was required to fix a latent bug in maybePrintfWrapper's
handling of format string parameters` declared using "factored"
syntax, such as: func f(foo, format string, args...interface{}).
See L253 of the original testdata file for a testcase that ensured
the buggy (?) behavior.
- func printfLike is removed as it was deadcode.
- isFormatter is rewritten to avoid a global variable.
- "if verbose { warn }" is replaced by "if false { report }" for now.
- recursive stringer is rewritten more simply in term of go/types.
Change-Id: Ia6ee827117b611c686e38207916a21fe1fc296e2
Reviewed-on: https://go-review.googlesource.com/c/142239
Reviewed-by: Michael Matloob <matloob@golang.org>
This is just a rename for ease of review.
The logic change will follow.
Change-Id: I8856b22f2157d63c6983c0f00a12c87e5d5dd1a4
Reviewed-on: https://go-review.googlesource.com/c/142357
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
CL 121876 made sync.noCopy implement sync.Locker and
added this as an assumption to vet. But now that copylock
is no longer in the standard library it cannot
assume that it is analyzing a recent standard library
in which noCopy has an Unlock method.
Change-Id: I5a30b3711ae6cc0855eb246fdd93b1906779bdde
Reviewed-on: https://go-review.googlesource.com/c/141683
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>