Build cache, go vet experiment, go list in Go 1.11 etc

[Paul Jolly]

Hi all (mainly Russ?),

I have a question regarding the build cache changes introduced in Go 1.10, specifically how it's envisaged that programs that use go/types will/might be able to load accurate type information in Go >= 1.11. 

As of 1.10, go vet now always has access to up-to-date type information via the following experiment (if I've understood correctly): 

https://github.com/golang/go/blob/dfb0e4f6c744eb9bf629658bf7da313b2d1518e1/src/cmd/vet/main.go#L238-L243

Russ mentioned in the Go 1.11 planning email some changes he has in mind for go list related to this.

Is there Github issue/thread/equivalent I can follow that discusses how this information (equivalent of vetConfig, or a build cache-aware implementation of go/types.Importer perhaps) can be made more generally available to programs that use go/types and require up-to-date type information?

Many thanks,

Paul

[Ian Lance Taylor]

It seems to me that you can just use go/types. What do you see the go
tool doing here?

Ian

[Russ Cox]

I don't think there's a Github issue. The idea is to expose some equivalent of vetConfig through go list, and to integrate it into golang.org/x/tools/loader, and maybe even do a cleaned up version of that API as a standard go/loader in a later release. For Go 1.10 it suffices to run go install before running these tools, and then go/types will find them in the install location instead of the cache. But we definitely want to get to where the tools can find things in the cache directly, with help from the go command.

Russ

[Paul Jolly]

I don't think there's a Github issue. The idea is to expose some equivalent of vetConfig through go list, and to integrate it into golang.org/x/tools/loader, and maybe even do a cleaned up version of that API as a standard go/loader in a later release. For Go 1.10 it suffices to run go install before running these tools, and then go/types will find them in the install location instead of the cache. But we definitely want to get to where the tools can find things in the cache directly, with help from the go command.

Thanks for the detail, Russ. We're performing exactly the workaround you describe for now (albeit augmented with a file watcher-equivalent to keep the go install current).

Look forward to seeing how this develops.  

Paul

[Paul Jolly]

It seems to me that you can just use go/types.  What do you see the go
tool doing here?

Thanks, Ian. Russ' reply helps to clarify things.

Paul 

[Paul Jolly]

As a follow-up question, is it anticipated that the cache infrastructure/mechanism will be exposed in any way?

We now have build and test caches; I would like my code generators to follow the same pattern and only doing work when their respective inputs have changed with respect to some cache.

Of course this needn't rely on any of the infrastructure the go tool uses - if could be done entirely separately, albeit following a similar pattern - so I ask to understand the general direction from team's perspective before working out where to head next.

Thanks