Add a vet target in order to catch suspicious constructs
reported by go vet.
Vet has successfully detected problems in the past,
for example, see
482460c4c8fc36b1cd9468a41035a97b704fb77d4f3f85b16595fa353ee94bfe18b40d
Some vet flags are noisy. In particular, the following flags
reports a large amount of generally unharmful constructs:
-assign: check for useless assignments
-composites: check that composite literals used field-keyed
elements
-shadow: check for shadowed variables
-shadowstrict: whether to be strict about shadowing
-unreachable: check for unreachable code
In order to skip running the flags mentioned above, vet is
invoked on a directory basis with 'go tool vet .' since package-
level type-checking with 'go vet' doesn't accept flags.
Hence, each file is vetted in isolation, which is weaker than
package-level type-checking. But nevertheless, it might catch
suspicious constructs that pose a real problem.
The vet target runs the following flags on the entire repo:
-asmdecl: check assembly against Go declarations
-atomic: check for common mistaken usages of the
sync/atomic package
-bool: check for mistakes involving boolean operators
-buildtags: check that +build tags are valid
-copylocks: check that locks are not passed by value
-methods: check that canonically named methods are canonically
defined
-nilfunc: check for comparisons between functions and nil
-printf: check printf-like invocations
-rangeloops: check that range loop variables are used correctly
-shift: check for useless shifts
-structtags: check that struct field tags have canonical format
and apply to exported fields as needed
-unsafeptr: check for misuse of unsafe.Pointer
Now and then, it might make sense to check the output of
VETARGS=-unreachable make vet
manually, just in case it detects several lines of dead code etc.
`go get -u` now checks that remote repo paths match the ones predicted
by the import paths.
So if working on TF from a forked repo, you cannot use `updatedeps` as
`go get` will complain about the differences between the import and the
path to your fork.
This is a refactored solution for PR #616. Functionally this is still
the same change, but it’s implemented a lot cleaner with less code and
less changes to existing parts of TF.
Paul Hinze