Redesign fixImports to have a clearer workflow, and hopefully create
clear places to plug in go/packages. This change is mostly
performance/functionality neutral, but does clean up some corner cases.
The new flow centers around the pass type, which encapsulates the
process of loading information about the current code, adding possible
new imports, and trying to apply them. I'm hoping that it's easy to
understand what's happening just by reading fixImports, and that new
sources of information (e.g. a network service) fit well into that flow.
Where possible, I left the functions near where they were extracted in
hopes of making review easier, but it's probably not going to be easy.
Sorry. I might move them into a more reasonable order in a followup CL.
Notable modifications:
- The stdlib cache is restructured to match pass' internal storage.
- Sibling imports with conflicting names are considered.
- Package name lookups are batched, hopefully making it easier to plug
in go/packages.
Questions that might be worth answering:
- Should findImportGoPath really scan $GOROOT? Unless the user is working
on a development copy, it's totally redundant with the cache.
- What is the best way to combine candidates from multiple sources?
Right now the first one wins, and findStdlibCandidates relies on that
to get crypto/rand ahead of math/rand.
- In the third pass, should it assume sibling imports or should it
actually go load the exports? It didn't load them before, but that seems
arbitrary.
Change-Id: Ie4ad0b69bfbe9b16883f2b0517b1278575c9f540
Reviewed-on: https://go-review.googlesource.com/c/150339
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Go 1.11 has been released; it's time to update zstdlib so
imports knows about API additions that went into Go 1.11.
Unfortunately, this does not include the syscall/js package
that was added in Go 1.11 for WebAssembly. This is because
it's not included in the GOROOT/api/go1.11.txt file. Getting
it into imports can/will be done in a future CL (after some
discussion of the best way to do it).
Previously:
- https://golang.org/cl/93195 (Go 1.10)
- https://golang.org/cl/49150 (Go 1.9)
Updates golang/go#27590.
Change-Id: I229d7c0a658b0d8090b58cfe844c95b4cb0b2212
Reviewed-on: https://go-review.googlesource.com/134176
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We're at beta 2 already, so the API is likely stable.
If anything gets rolled back, we can update imports again.
Change-Id: I87e0adde062e45cab16e2bee2f929c1ac1bb828d
Reviewed-on: https://go-review.googlesource.com/49150
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fast path for the common case. Avoids scanning GOPATH usually.
LGTM=r, crawshaw
R=david.crawshaw, adg, r, crawshaw
CC=golang-codereviews
https://golang.org/cl/56820043
