The comments for the require package were just copied over
from the assert package when generating the functions.
This could lead to confusion because
1. The code-examples were showing examples using the
assert package instead of the require package
2. The function-documentation was not mentioning that
the functions were calling `t.FailNow()` which is some
critical information when using this package.
Fix two issues with codegen that cause it not to work with Go Modules.
1. When parsing the code files the package SrcRoot and ImportPath were
being joined which assumes the package is hosted inside a GOPATH src
directory. Using those two fields is unnecessary because a package also
knows what directory it lives in, which is in the Dir field. This change
switches to using the Dir field.
2. When checking the types in the source files the default importer is
being used. Unfortunately the default importer has not been updated to
work with Go Modules and it only looks in the GOPATH for imports.
Luckily the Go team were convinced to backport some logic from the newer
go/packages package to go/build, and we can make use of the go/build
importer which supports Go Modules. One downside of using the go/build
importer is it is said to be slow. For this size project though it's I
don't think it's a problem.
In the future codegen should be rewritten to use go/packages once it is
included in the stdlib. go/packages currently lives at
golang.org/x/tools/go/packages. Once it is in the stdlib I believe it
will replace go/build.
Both fixes are compatible with Go 1.13, Go 1.12, Go 1.11, Go 1.10.
I've also updated the TravisCI config to run go generate, and to add the
newer versions of Go to demonstrate that this works on all versions of
Go.
Simon Schulte
Olivier Mengué
arseny
Matt Gorzka
Leigh McCulloch
Ernesto Jiménez
Nick Miyake