Граф коммитов

6 Коммитов

Автор SHA1 Сообщение Дата
Heschi Kreinick 9c309ee22f imports: stop using go/packages for modules
go/packages needs to call `go list` multiple times, which causes
redundant work and slows down goimports. If we reimplement `go list` in
memory, we can reuse state, saving time. `go list` also does work we
don't really need, like adding stuff to go.mod, and skipping that saves
more time.

We start with `go list -m`, which does MVS and such. The remaining work
is mostly mapping import paths and directories through the in-scope
modules to make sure we're giving the right answers. Unfortunately this
is quite subtle, and I don't know where all the traps are. I did my
best.

cmd/go already has tests for `go list`, of course, and packagestest is
not well suited to tests of this complexity. So I ripped off the script
tests in cmd/go that seemed relevant and made sure that our logic
returns the right stuff in each case. I'm sure that there are more cases
to cover, but this hit all the stuff I knew about and quite a bit I
didn't.

Since we may want to use the go/packages code path in the future, e.g.
for Bazel, I left that in place. It won't be used unless the magic env
var is set.

Files in internal and imports/testdata/mod were copied verbatim from
cmd/go.

Change-Id: I1248d99c400c1a0c7ef180d4460b9b8a3db0246b
Reviewed-on: https://go-review.googlesource.com/c/158097
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
2019-01-22 20:29:12 +00:00
Heschi Kreinick 16909d206f imports: remove globals, stop using build.Default
The imports package's public API is build.Default, but that doesn't mean
we need to use it in the internal implementation or the tests. Now we
have a new type, fixEnv, that contains everything relevant from
build.Context, as well as the various global vars that were only used
for testing.

Don't worry too much about the new function parameters; they mostly
move into the resolvers in the next CL.

Refactoring only; no user-visible changes intended.

Change-Id: I0d4c904955c5854dcdf904009cb3413c734baf88
Reviewed-on: https://go-review.googlesource.com/c/158437
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
2019-01-18 19:33:59 +00:00
Heschi Kreinick 42c3d2e9aa internal/gopathwalk: ignore $GOROOT/.../vendor/ in module mode
go list in module mode doesn't like looking at vendor directories in
GOROOT. Skip them.

Change-Id: Iec501fbab70914ea6dd76dcbed97ecda461358d0
Reviewed-on: https://go-review.googlesource.com/c/148159
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
2018-11-07 20:51:50 +00:00
Heschi Kreinick 654e6e76cd gopathwalk: don't log for nonexistant root dirs
If users don't have a module cache yet, or put a nonexistant directory
in their GOPATH, it doesn't make sense to print an error. Just ignore it
and move on.

No tests; I don't think it makes sense to set up log scraping for this.

Change-Id: I90719297ade37999e8b401767a0a37c940828c27
Reviewed-on: https://go-review.googlesource.com/c/142977
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
2018-10-17 18:30:23 +00:00
Heschi Kreinick 63d31665e3 go/packages: add name= query
Add an implementation of name= for go list. It will be used to
implement goimports and godoc-like lookups by package name.

Imported a copy of the semver package from the stdlib to do version
comparison, and tweaked the gopathwalk API to include a hint about what
kind of source directory is being traversed.

Note that the tests, despite my best efforts, are not hermetic: go list
insists on doing version lookups in situations where it seems to me like
it shouldn't need to.

I think this implementation is ready for serious use. The one thing I'm
nervous about is that it currently does a substring match when looking
for a package name, so if you look up a package named "a" you will get
a huge number of results. This matches goimports' behavior but I don't
know if it's suitable for general use.

Change-Id: I2b7f823b74571fe30d3bd9c7dfafb4e6a40df5d3
Reviewed-on: https://go-review.googlesource.com/c/138878
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
2018-10-16 20:20:09 +00:00
Heschi Kreinick 19e2aca3fd internal/gopathwalk: create
Extract goimports' logic for walking Go source directories into a
separate package, suitable for use in go/packages. No functional
changes. Added a convenience feature to fastwalk, allowing the user to
say that they're done with a directory and stop receiving callbacks for
it.

Testing is a little light; I expect goimports' tests to cover most
everything we care about.

Change-Id: If047ada4414f5f282637d11fd07e8342fadc9c33
Reviewed-on: https://go-review.googlesource.com/c/138877
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-10-12 18:13:39 +00:00