wire: use go/packages for analysis

[zombiezen]

Unfortunately, this does come with a ~4x slowdown to Wire, as it is now pulling source for all transitively depended packages, but not trimming comments or function bodies. This is due to limitations with the ParseFile callback in go/packages.

This comes with a single semantic change: when performing analysis, Wire will now evaluate everything with the wireinject build tag. I updated the build tags tests accordingly.

I deleted the vendoring test, as vendoring becomes obsolete with modules.

go/packages now parses comments by default, so now the generated code includes comments for non-injector declarations.

Fixes #78

[vangent]

Tests are failing....

[zombiezen]

Investigating. This is a new failure to me.

[vangent]

The changes look fine to me, once tests are passing :-).

This comes with a single semantic change: when performing analysis, Wire will now evaluate
everything with the wireinject build tag.

Can you clarify -- what did it do before?

[zombiezen]

Prior to this PR, only the packages directly named by the package patterns would be evaluated with the wireinject build tag. Dependencies would not have the wireinject build tag applied. There isn't a way to selectively apply build tags in go/packages, and there isn't a clear benefit to applying it selectively. Being consistent with other Go tooling provides greater benefit.

[jba]

vendoring becomes obsolete with modules

Aren't top-level vendor directories still supported?

[zombiezen]

@jba They are, but the semantics as they pertain to Wire have changed: such a vendored directory used to silently be myproject/vendor/example.com/foo, whereas now it just appears as example.com/foo in the graph. (Maintaining that test was also going to require plumbing the -mod=vendor build flag through the stack, which I was not inclined to do.)

Note to other contributors: please don't merge this yet. I don't have an explanation for the original build failure yet. In the meantime, I have pushed seemingly identical code and the tests passed. :|

[zombiezen]

OK, tests pass AFAICT. The Mac failure is legitimate and has been addressed by calling filepath.EvalSymlinks on the returned directory name. However, I remain unable to reproduce the original Linux failure of:

go [list -e -json -compiled -test=false -export=false -deps=true -tags=wireinject -- example.com/foo]: exit status 1: build example.com/foo: cannot find module for path github.com/google/go-cloud/wire

I am apprehensive that I might be somehow introducing a nondeterministic test. However, I have no plausible hypotheses as to the source of the failure, so I don't know what to log in order to monitor the failure in the future. Possibilities that I've ruled out:

• Not related to GO111MODULE setting: I have tried both on and off on my local machine.
• Not related to Travis userspace: I downloaded the Travis Docker image and could not reproduce, and also can't get the failure to happen reliably on Travis.
• Not related to go.mod quoting: passes either way on Travis
• Not related to TMPDIR setting: Travis does not set TMPDIR, only TRAVIS_TMPDIR, and Go will use /tmp in this case.
• GOPATH is being materialized correctly: I checked the file names being created and they align with my expectations.

@vangent, please review, but please do not merge. I would like to do another pass at editing the commit message before it goes in.