cmd/vet: switch to new srcimporter

[josharian]

Go 1.9 has a new source-based importer. I'd like to switch cmd/vet to it. This will resolve a host of open issues.

It should also make cmd/vet/all a lot faster, which would be good, since @bradfitz is a bit concerned about kubernetes CPU capacity at the moment.

cc @robpike @griesemer @valyala

[griesemer]

I'd like to complete this work first; i.e., also implement an "gc/auto" importer which automatically decides whether to use installed packages or source (whichever is newer). And then make this "auto" importer the default importer. As a consequence, programs that just use the default importer wouldn't have to change at all.

Any objections?

[josharian]

Sounds great.

[griesemer]

Per #11415 (comment) I think this should go forward with the "source" importer, rather than waiting for an "auto" importer.

[gopherbot]

CL https://golang.org/cl/37690 mentions this issue.

[myitcv]

@josharian

It should also make cmd/vet/all a lot faster

I might be missing something here, but won't it do the opposite? i.e. make cmd/vet run slower?

[josharian]

See the numbers in https://go-review.googlesource.com/c/37691/.

cmd/vet/all currently has to do 'go install' in order to typecheck the files, which invokes cmd/compile, which is (unsurprisingly) heavier-weight than go/types. For cases in which the relevant packages have already been compiled, using the installed object files will be faster. That will remain the default for cmd/vet.

[myitcv]

Thanks for the link: I understand the context now.

For cases in which the relevant packages have already been compiled, using the installed object files will be faster.

That's what I was getting at. My concern here was that for situations where packages are up to date there would be a needless hit by vet being moved over to the source importer (the exact use case of the "auto" importer)

... That will remain the default for cmd/vet.

Thanks for clarifying.