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-16 14:24:49 -07:00
|
|
|
package imports
|
|
|
|
|
|
|
|
import (
|
|
|
|
"bytes"
|
2019-08-02 11:04:42 -06:00
|
|
|
"context"
|
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-16 14:24:49 -07:00
|
|
|
"encoding/json"
|
2019-08-02 12:05:22 -06:00
|
|
|
"fmt"
|
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-16 14:24:49 -07:00
|
|
|
"io/ioutil"
|
|
|
|
"os"
|
|
|
|
"path"
|
|
|
|
"path/filepath"
|
|
|
|
"regexp"
|
|
|
|
"sort"
|
|
|
|
"strconv"
|
|
|
|
"strings"
|
|
|
|
"sync"
|
|
|
|
|
|
|
|
"golang.org/x/tools/internal/gopathwalk"
|
|
|
|
"golang.org/x/tools/internal/module"
|
2019-10-23 15:36:29 -06:00
|
|
|
"golang.org/x/tools/internal/semver"
|
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-16 14:24:49 -07:00
|
|
|
)
|
|
|
|
|
2019-07-03 13:23:05 -06:00
|
|
|
// ModuleResolver implements resolver for modules using the go command as little
|
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-16 14:24:49 -07:00
|
|
|
// as feasible.
|
2019-07-03 13:23:05 -06:00
|
|
|
type ModuleResolver struct {
|
2019-08-20 13:39:18 -06:00
|
|
|
env *ProcessEnv
|
|
|
|
moduleCacheDir string
|
2019-10-23 15:36:29 -06:00
|
|
|
dummyVendorMod *ModuleJSON // If vendoring is enabled, the pseudo-module that represents the /vendor directory.
|
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-16 14:24:49 -07:00
|
|
|
|
2019-07-03 13:23:05 -06:00
|
|
|
Initialized bool
|
|
|
|
Main *ModuleJSON
|
|
|
|
ModsByModPath []*ModuleJSON // All modules, ordered by # of path components in module Path...
|
|
|
|
ModsByDir []*ModuleJSON // ...or Dir.
|
2019-07-16 15:37:05 -06:00
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
// moduleCacheCache stores information about the module cache.
|
|
|
|
moduleCacheCache *dirInfoCache
|
|
|
|
otherCache *dirInfoCache
|
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-16 14:24:49 -07:00
|
|
|
}
|
|
|
|
|
2019-07-03 13:23:05 -06:00
|
|
|
type ModuleJSON struct {
|
2019-10-23 15:36:29 -06:00
|
|
|
Path string // module path
|
|
|
|
Replace *ModuleJSON // replaced by this module
|
|
|
|
Main bool // is this the main module?
|
|
|
|
Dir string // directory holding files for this module, if any
|
|
|
|
GoMod string // path to go.mod file for this module, if any
|
|
|
|
GoVersion string // go version used in module
|
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-16 14:24:49 -07:00
|
|
|
}
|
|
|
|
|
2019-07-03 13:23:05 -06:00
|
|
|
func (r *ModuleResolver) init() error {
|
|
|
|
if r.Initialized {
|
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-16 14:24:49 -07:00
|
|
|
return nil
|
|
|
|
}
|
2019-10-23 15:36:29 -06:00
|
|
|
mainMod, vendorEnabled, err := vendorEnabled(r.env)
|
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-16 14:24:49 -07:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2019-10-23 15:36:29 -06:00
|
|
|
|
|
|
|
if mainMod != nil && vendorEnabled {
|
|
|
|
// Vendor mode is on, so all the non-Main modules are irrelevant,
|
|
|
|
// and we need to search /vendor for everything.
|
|
|
|
r.Main = mainMod
|
|
|
|
r.dummyVendorMod = &ModuleJSON{
|
|
|
|
Path: "",
|
|
|
|
Dir: filepath.Join(mainMod.Dir, "vendor"),
|
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-16 14:24:49 -07:00
|
|
|
}
|
2019-10-23 15:36:29 -06:00
|
|
|
r.ModsByModPath = []*ModuleJSON{mainMod, r.dummyVendorMod}
|
|
|
|
r.ModsByDir = []*ModuleJSON{mainMod, r.dummyVendorMod}
|
|
|
|
} else {
|
|
|
|
// Vendor mode is off, so run go list -m ... to find everything.
|
|
|
|
r.initAllMods()
|
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-16 14:24:49 -07:00
|
|
|
}
|
|
|
|
|
2019-10-23 15:36:29 -06:00
|
|
|
r.moduleCacheDir = filepath.Join(filepath.SplitList(r.env.GOPATH)[0], "/pkg/mod")
|
|
|
|
|
2019-07-03 13:23:05 -06:00
|
|
|
sort.Slice(r.ModsByModPath, func(i, j int) bool {
|
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-16 14:24:49 -07:00
|
|
|
count := func(x int) int {
|
2019-07-03 13:23:05 -06:00
|
|
|
return strings.Count(r.ModsByModPath[x].Path, "/")
|
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-16 14:24:49 -07:00
|
|
|
}
|
|
|
|
return count(j) < count(i) // descending order
|
|
|
|
})
|
2019-07-03 13:23:05 -06:00
|
|
|
sort.Slice(r.ModsByDir, func(i, j int) bool {
|
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-16 14:24:49 -07:00
|
|
|
count := func(x int) int {
|
2019-07-03 13:23:05 -06:00
|
|
|
return strings.Count(r.ModsByDir[x].Dir, "/")
|
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-16 14:24:49 -07:00
|
|
|
}
|
|
|
|
return count(j) < count(i) // descending order
|
|
|
|
})
|
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
if r.moduleCacheCache == nil {
|
|
|
|
r.moduleCacheCache = &dirInfoCache{
|
|
|
|
dirs: map[string]*directoryPackageInfo{},
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if r.otherCache == nil {
|
|
|
|
r.otherCache = &dirInfoCache{
|
|
|
|
dirs: map[string]*directoryPackageInfo{},
|
2019-08-02 12:05:22 -06:00
|
|
|
}
|
|
|
|
}
|
2019-07-03 13:23:05 -06:00
|
|
|
r.Initialized = true
|
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-16 14:24:49 -07:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2019-10-23 15:36:29 -06:00
|
|
|
func (r *ModuleResolver) initAllMods() error {
|
|
|
|
stdout, err := r.env.invokeGo("list", "-m", "-json", "...")
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
for dec := json.NewDecoder(stdout); dec.More(); {
|
|
|
|
mod := &ModuleJSON{}
|
|
|
|
if err := dec.Decode(mod); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if mod.Dir == "" {
|
|
|
|
if r.env.Debug {
|
|
|
|
r.env.Logf("module %v has not been downloaded and will be ignored", mod.Path)
|
|
|
|
}
|
|
|
|
// Can't do anything with a module that's not downloaded.
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
r.ModsByModPath = append(r.ModsByModPath, mod)
|
|
|
|
r.ModsByDir = append(r.ModsByDir, mod)
|
|
|
|
if mod.Main {
|
|
|
|
r.Main = mod
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
func (r *ModuleResolver) ClearForNewScan() {
|
|
|
|
r.otherCache = &dirInfoCache{
|
|
|
|
dirs: map[string]*directoryPackageInfo{},
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func (r *ModuleResolver) ClearForNewMod() {
|
|
|
|
env := r.env
|
|
|
|
*r = ModuleResolver{
|
|
|
|
env: env,
|
|
|
|
}
|
|
|
|
r.init()
|
|
|
|
}
|
|
|
|
|
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-16 14:24:49 -07:00
|
|
|
// findPackage returns the module and directory that contains the package at
|
|
|
|
// the given import path, or returns nil, "" if no module is in scope.
|
2019-07-03 13:23:05 -06:00
|
|
|
func (r *ModuleResolver) findPackage(importPath string) (*ModuleJSON, string) {
|
2019-09-10 14:48:19 -06:00
|
|
|
// This can't find packages in the stdlib, but that's harmless for all
|
|
|
|
// the existing code paths.
|
2019-07-03 13:23:05 -06:00
|
|
|
for _, m := range r.ModsByModPath {
|
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-16 14:24:49 -07:00
|
|
|
if !strings.HasPrefix(importPath, m.Path) {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
pathInModule := importPath[len(m.Path):]
|
|
|
|
pkgDir := filepath.Join(m.Dir, pathInModule)
|
2019-08-20 13:39:18 -06:00
|
|
|
if r.dirIsNestedModule(pkgDir, m) {
|
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-16 14:24:49 -07:00
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
if info, ok := r.cacheLoad(pkgDir); ok {
|
2019-10-04 13:38:18 -06:00
|
|
|
if loaded, err := info.reachedStatus(nameLoaded); loaded {
|
2019-07-19 13:21:23 -06:00
|
|
|
if err != nil {
|
2019-10-04 13:38:18 -06:00
|
|
|
continue // No package in this dir.
|
2019-07-19 13:21:23 -06:00
|
|
|
}
|
|
|
|
return m, pkgDir
|
|
|
|
}
|
2019-10-04 13:38:18 -06:00
|
|
|
if scanned, err := info.reachedStatus(directoryScanned); scanned && err != nil {
|
|
|
|
continue // Dir is unreadable, etc.
|
|
|
|
}
|
2019-10-09 17:05:30 -06:00
|
|
|
// This is slightly wrong: a directory doesn't have to have an
|
|
|
|
// importable package to count as a package for package-to-module
|
|
|
|
// resolution. package main or _test files should count but
|
|
|
|
// don't.
|
|
|
|
// TODO(heschi): fix this.
|
|
|
|
if _, err := r.cachePackageName(pkgDir); err == nil {
|
|
|
|
return m, pkgDir
|
|
|
|
}
|
2019-07-19 13:21:23 -06:00
|
|
|
}
|
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
// Not cached. Read the filesystem.
|
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-16 14:24:49 -07:00
|
|
|
pkgFiles, err := ioutil.ReadDir(pkgDir)
|
|
|
|
if err != nil {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
// A module only contains a package if it has buildable go
|
|
|
|
// files in that directory. If not, it could be provided by an
|
|
|
|
// outer module. See #29736.
|
|
|
|
for _, fi := range pkgFiles {
|
|
|
|
if ok, _ := r.env.buildContext().MatchFile(pkgDir, fi.Name()); ok {
|
|
|
|
return m, pkgDir
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nil, ""
|
|
|
|
}
|
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
func (r *ModuleResolver) cacheLoad(dir string) (directoryPackageInfo, bool) {
|
|
|
|
if info, ok := r.moduleCacheCache.Load(dir); ok {
|
|
|
|
return info, ok
|
|
|
|
}
|
|
|
|
return r.otherCache.Load(dir)
|
|
|
|
}
|
|
|
|
|
|
|
|
func (r *ModuleResolver) cacheStore(info directoryPackageInfo) {
|
|
|
|
if info.rootType == gopathwalk.RootModuleCache {
|
|
|
|
r.moduleCacheCache.Store(info.dir, info)
|
|
|
|
} else {
|
|
|
|
r.otherCache.Store(info.dir, info)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func (r *ModuleResolver) cacheKeys() []string {
|
|
|
|
return append(r.moduleCacheCache.Keys(), r.otherCache.Keys()...)
|
|
|
|
}
|
|
|
|
|
|
|
|
// cachePackageName caches the package name for a dir already in the cache.
|
|
|
|
func (r *ModuleResolver) cachePackageName(dir string) (directoryPackageInfo, error) {
|
|
|
|
info, ok := r.cacheLoad(dir)
|
|
|
|
if !ok {
|
|
|
|
panic("cachePackageName on uncached dir " + dir)
|
|
|
|
}
|
|
|
|
|
|
|
|
loaded, err := info.reachedStatus(nameLoaded)
|
|
|
|
if loaded {
|
|
|
|
return info, err
|
|
|
|
}
|
|
|
|
info.packageName, info.err = packageDirToName(info.dir)
|
|
|
|
info.status = nameLoaded
|
|
|
|
r.cacheStore(info)
|
|
|
|
return info, info.err
|
|
|
|
}
|
|
|
|
|
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-16 14:24:49 -07:00
|
|
|
// findModuleByDir returns the module that contains dir, or nil if no such
|
|
|
|
// module is in scope.
|
2019-07-03 13:23:05 -06:00
|
|
|
func (r *ModuleResolver) findModuleByDir(dir string) *ModuleJSON {
|
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-16 14:24:49 -07:00
|
|
|
// This is quite tricky and may not be correct. dir could be:
|
|
|
|
// - a package in the main module.
|
|
|
|
// - a replace target underneath the main module's directory.
|
|
|
|
// - a nested module in the above.
|
|
|
|
// - a replace target somewhere totally random.
|
|
|
|
// - a nested module in the above.
|
|
|
|
// - in the mod cache.
|
|
|
|
// - in /vendor/ in -mod=vendor mode.
|
|
|
|
// - nested module? Dunno.
|
|
|
|
// Rumor has it that replace targets cannot contain other replace targets.
|
2019-07-03 13:23:05 -06:00
|
|
|
for _, m := range r.ModsByDir {
|
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-16 14:24:49 -07:00
|
|
|
if !strings.HasPrefix(dir, m.Dir) {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
2019-08-20 13:39:18 -06:00
|
|
|
if r.dirIsNestedModule(dir, m) {
|
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-16 14:24:49 -07:00
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
return m
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// dirIsNestedModule reports if dir is contained in a nested module underneath
|
|
|
|
// mod, not actually in mod.
|
2019-08-20 13:39:18 -06:00
|
|
|
func (r *ModuleResolver) dirIsNestedModule(dir string, mod *ModuleJSON) bool {
|
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-16 14:24:49 -07:00
|
|
|
if !strings.HasPrefix(dir, mod.Dir) {
|
|
|
|
return false
|
|
|
|
}
|
2019-08-20 13:39:18 -06:00
|
|
|
if r.dirInModuleCache(dir) {
|
|
|
|
// Nested modules in the module cache are pruned,
|
|
|
|
// so it cannot be a nested module.
|
|
|
|
return false
|
|
|
|
}
|
2019-10-23 15:36:29 -06:00
|
|
|
if mod != nil && mod == r.dummyVendorMod {
|
|
|
|
// The /vendor pseudomodule is flattened and doesn't actually count.
|
|
|
|
return false
|
|
|
|
}
|
2019-10-21 15:48:25 -06:00
|
|
|
modDir, _ := r.modInfo(dir)
|
|
|
|
if modDir == "" {
|
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-16 14:24:49 -07:00
|
|
|
return false
|
|
|
|
}
|
2019-10-21 15:48:25 -06:00
|
|
|
return modDir != mod.Dir
|
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-16 14:24:49 -07:00
|
|
|
}
|
|
|
|
|
2019-10-21 15:48:25 -06:00
|
|
|
func (r *ModuleResolver) modInfo(dir string) (modDir string, modName string) {
|
|
|
|
readModName := func(modFile string) string {
|
|
|
|
modBytes, err := ioutil.ReadFile(modFile)
|
|
|
|
if err != nil {
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
return modulePath(modBytes)
|
|
|
|
}
|
|
|
|
|
2019-08-20 13:39:18 -06:00
|
|
|
if r.dirInModuleCache(dir) {
|
|
|
|
matches := modCacheRegexp.FindStringSubmatch(dir)
|
|
|
|
index := strings.Index(dir, matches[1]+"@"+matches[2])
|
2019-10-21 15:48:25 -06:00
|
|
|
modDir := filepath.Join(dir[:index], matches[1]+"@"+matches[2])
|
|
|
|
return modDir, readModName(filepath.Join(modDir, "go.mod"))
|
2019-08-20 13:39:18 -06:00
|
|
|
}
|
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-16 14:24:49 -07:00
|
|
|
for {
|
2019-10-21 15:48:25 -06:00
|
|
|
if info, ok := r.cacheLoad(dir); ok {
|
|
|
|
return info.moduleDir, info.moduleName
|
|
|
|
}
|
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-16 14:24:49 -07:00
|
|
|
f := filepath.Join(dir, "go.mod")
|
|
|
|
info, err := os.Stat(f)
|
|
|
|
if err == nil && !info.IsDir() {
|
2019-10-21 15:48:25 -06:00
|
|
|
return dir, readModName(f)
|
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-16 14:24:49 -07:00
|
|
|
}
|
2019-10-21 15:48:25 -06:00
|
|
|
|
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-16 14:24:49 -07:00
|
|
|
d := filepath.Dir(dir)
|
|
|
|
if len(d) >= len(dir) {
|
2019-10-21 15:48:25 -06:00
|
|
|
return "", "" // reached top of file system, no go.mod
|
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-16 14:24:49 -07:00
|
|
|
}
|
|
|
|
dir = d
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-08-20 13:39:18 -06:00
|
|
|
func (r *ModuleResolver) dirInModuleCache(dir string) bool {
|
|
|
|
if r.moduleCacheDir == "" {
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
return strings.HasPrefix(dir, r.moduleCacheDir)
|
|
|
|
}
|
|
|
|
|
2019-07-03 13:23:05 -06:00
|
|
|
func (r *ModuleResolver) loadPackageNames(importPaths []string, srcDir string) (map[string]string, error) {
|
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-16 14:24:49 -07:00
|
|
|
if err := r.init(); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
names := map[string]string{}
|
|
|
|
for _, path := range importPaths {
|
|
|
|
_, packageDir := r.findPackage(path)
|
|
|
|
if packageDir == "" {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
name, err := packageDirToName(packageDir)
|
|
|
|
if err != nil {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
names[path] = name
|
|
|
|
}
|
|
|
|
return names, nil
|
|
|
|
}
|
|
|
|
|
2019-10-04 13:38:18 -06:00
|
|
|
func (r *ModuleResolver) scan(_ references, loadNames bool, exclude []gopathwalk.RootType) ([]*pkg, error) {
|
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-16 14:24:49 -07:00
|
|
|
if err := r.init(); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
// Walk GOROOT, GOPATH/pkg/mod, and the main module.
|
|
|
|
roots := []gopathwalk.Root{
|
|
|
|
{filepath.Join(r.env.GOROOT, "/src"), gopathwalk.RootGOROOT},
|
2019-03-15 13:21:23 -06:00
|
|
|
}
|
2019-07-03 13:23:05 -06:00
|
|
|
if r.Main != nil {
|
|
|
|
roots = append(roots, gopathwalk.Root{r.Main.Dir, gopathwalk.RootCurrentModule})
|
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-16 14:24:49 -07:00
|
|
|
}
|
2019-10-23 15:36:29 -06:00
|
|
|
if r.dummyVendorMod != nil {
|
|
|
|
roots = append(roots, gopathwalk.Root{r.dummyVendorMod.Dir, gopathwalk.RootOther})
|
|
|
|
} else {
|
|
|
|
roots = append(roots, gopathwalk.Root{r.moduleCacheDir, gopathwalk.RootModuleCache})
|
|
|
|
// Walk replace targets, just in case they're not in any of the above.
|
|
|
|
for _, mod := range r.ModsByModPath {
|
|
|
|
if mod.Replace != nil {
|
|
|
|
roots = append(roots, gopathwalk.Root{mod.Dir, gopathwalk.RootOther})
|
|
|
|
}
|
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-16 14:24:49 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-10-04 13:38:18 -06:00
|
|
|
roots = filterRoots(roots, exclude)
|
|
|
|
|
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-16 14:24:49 -07:00
|
|
|
var result []*pkg
|
|
|
|
var mu sync.Mutex
|
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
// We assume cached directories have not changed. We can skip them and their
|
|
|
|
// children.
|
2019-07-19 10:41:29 -06:00
|
|
|
skip := func(root gopathwalk.Root, dir string) bool {
|
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-16 14:24:49 -07:00
|
|
|
mu.Lock()
|
|
|
|
defer mu.Unlock()
|
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
info, ok := r.cacheLoad(dir)
|
2019-07-19 10:41:29 -06:00
|
|
|
if !ok {
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
// This directory can be skipped as long as we have already scanned it.
|
|
|
|
// Packages with errors will continue to have errors, so there is no need
|
|
|
|
// to rescan them.
|
|
|
|
packageScanned, _ := info.reachedStatus(directoryScanned)
|
|
|
|
return packageScanned
|
|
|
|
}
|
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-16 14:24:49 -07:00
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
// Add anything new to the cache. We'll process everything in it below.
|
2019-07-19 10:41:29 -06:00
|
|
|
add := func(root gopathwalk.Root, dir string) {
|
|
|
|
mu.Lock()
|
|
|
|
defer mu.Unlock()
|
2019-07-16 15:37:05 -06:00
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
r.cacheStore(r.scanDirForPackage(root, dir))
|
2019-07-19 10:41:29 -06:00
|
|
|
}
|
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-16 14:24:49 -07:00
|
|
|
|
2019-07-19 10:41:29 -06:00
|
|
|
gopathwalk.WalkSkip(roots, add, skip, gopathwalk.Options{Debug: r.env.Debug, ModulesEnabled: true})
|
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
// Everything we already had, and everything new, is now in the cache.
|
|
|
|
for _, dir := range r.cacheKeys() {
|
|
|
|
info, ok := r.cacheLoad(dir)
|
2019-07-19 10:41:29 -06:00
|
|
|
if !ok {
|
|
|
|
continue
|
2019-07-16 15:37:05 -06:00
|
|
|
}
|
|
|
|
|
2019-07-19 10:41:29 -06:00
|
|
|
// Skip this directory if we were not able to get the package information successfully.
|
|
|
|
if scanned, err := info.reachedStatus(directoryScanned); !scanned || err != nil {
|
|
|
|
continue
|
2019-07-16 15:37:05 -06:00
|
|
|
}
|
|
|
|
|
2019-10-04 13:38:18 -06:00
|
|
|
// If we want package names, make sure the cache has them.
|
|
|
|
if loadNames {
|
2019-10-09 17:05:30 -06:00
|
|
|
var err error
|
|
|
|
if info, err = r.cachePackageName(info.dir); err != nil {
|
2019-10-04 13:38:18 -06:00
|
|
|
continue
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
res, err := r.canonicalize(info)
|
2019-07-19 10:41:29 -06:00
|
|
|
if err != nil {
|
|
|
|
continue
|
|
|
|
}
|
2019-07-16 15:37:05 -06:00
|
|
|
result = append(result, res)
|
2019-07-19 10:41:29 -06:00
|
|
|
}
|
|
|
|
|
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-16 14:24:49 -07:00
|
|
|
return result, nil
|
|
|
|
}
|
|
|
|
|
2019-07-19 10:41:29 -06:00
|
|
|
// canonicalize gets the result of canonicalizing the packages using the results
|
|
|
|
// of initializing the resolver from 'go list -m'.
|
2019-10-09 17:05:30 -06:00
|
|
|
func (r *ModuleResolver) canonicalize(info directoryPackageInfo) (*pkg, error) {
|
2019-09-12 14:41:22 -06:00
|
|
|
// Packages in GOROOT are already canonical, regardless of the std/cmd modules.
|
2019-10-09 17:05:30 -06:00
|
|
|
if info.rootType == gopathwalk.RootGOROOT {
|
2019-09-12 14:41:22 -06:00
|
|
|
return &pkg{
|
2019-10-04 13:38:18 -06:00
|
|
|
importPathShort: info.nonCanonicalImportPath,
|
|
|
|
dir: info.dir,
|
|
|
|
packageName: path.Base(info.nonCanonicalImportPath),
|
2019-09-12 14:41:22 -06:00
|
|
|
}, nil
|
|
|
|
}
|
|
|
|
|
2019-10-04 13:38:18 -06:00
|
|
|
importPath := info.nonCanonicalImportPath
|
2019-07-19 10:41:29 -06:00
|
|
|
// Check if the directory is underneath a module that's in scope.
|
2019-10-04 13:38:18 -06:00
|
|
|
if mod := r.findModuleByDir(info.dir); mod != nil {
|
2019-07-19 10:41:29 -06:00
|
|
|
// It is. If dir is the target of a replace directive,
|
|
|
|
// our guessed import path is wrong. Use the real one.
|
2019-10-04 13:38:18 -06:00
|
|
|
if mod.Dir == info.dir {
|
2019-07-19 10:41:29 -06:00
|
|
|
importPath = mod.Path
|
|
|
|
} else {
|
2019-10-04 13:38:18 -06:00
|
|
|
dirInMod := info.dir[len(mod.Dir)+len("/"):]
|
2019-07-19 10:41:29 -06:00
|
|
|
importPath = path.Join(mod.Path, filepath.ToSlash(dirInMod))
|
|
|
|
}
|
2019-10-04 13:38:18 -06:00
|
|
|
} else if info.needsReplace {
|
|
|
|
return nil, fmt.Errorf("package in %q is not valid without a replace statement", info.dir)
|
2019-07-19 10:41:29 -06:00
|
|
|
}
|
|
|
|
|
2019-10-04 13:38:18 -06:00
|
|
|
res := &pkg{
|
2019-10-23 15:36:29 -06:00
|
|
|
importPathShort: importPath,
|
2019-10-04 13:38:18 -06:00
|
|
|
dir: info.dir,
|
|
|
|
packageName: info.packageName, // may not be populated if the caller didn't ask for it
|
|
|
|
}
|
2019-07-19 10:41:29 -06:00
|
|
|
// We may have discovered a package that has a different version
|
|
|
|
// in scope already. Canonicalize to that one if possible.
|
|
|
|
if _, canonicalDir := r.findPackage(importPath); canonicalDir != "" {
|
2019-10-04 13:38:18 -06:00
|
|
|
res.dir = canonicalDir
|
2019-07-19 10:41:29 -06:00
|
|
|
}
|
2019-10-04 13:38:18 -06:00
|
|
|
return res, nil
|
2019-07-19 10:41:29 -06:00
|
|
|
}
|
|
|
|
|
2019-08-02 11:04:42 -06:00
|
|
|
func (r *ModuleResolver) loadExports(ctx context.Context, expectPackage string, pkg *pkg) (map[string]bool, error) {
|
|
|
|
if err := r.init(); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return loadExportsFromFiles(ctx, r.env, expectPackage, pkg.dir)
|
|
|
|
}
|
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
func (r *ModuleResolver) scanDirForPackage(root gopathwalk.Root, dir string) directoryPackageInfo {
|
2019-08-02 12:05:22 -06:00
|
|
|
subdir := ""
|
|
|
|
if dir != root.Path {
|
|
|
|
subdir = dir[len(root.Path)+len("/"):]
|
|
|
|
}
|
|
|
|
importPath := filepath.ToSlash(subdir)
|
|
|
|
if strings.HasPrefix(importPath, "vendor/") {
|
2019-10-23 15:36:29 -06:00
|
|
|
// Only enter vendor directories if they're explicitly requested as a root.
|
2019-10-09 17:05:30 -06:00
|
|
|
return directoryPackageInfo{
|
|
|
|
status: directoryScanned,
|
2019-10-23 15:36:29 -06:00
|
|
|
err: fmt.Errorf("unwanted vendor directory"),
|
2019-10-09 17:05:30 -06:00
|
|
|
}
|
2019-08-02 12:05:22 -06:00
|
|
|
}
|
|
|
|
switch root.Type {
|
|
|
|
case gopathwalk.RootCurrentModule:
|
|
|
|
importPath = path.Join(r.Main.Path, filepath.ToSlash(subdir))
|
|
|
|
case gopathwalk.RootModuleCache:
|
|
|
|
matches := modCacheRegexp.FindStringSubmatch(subdir)
|
2019-09-04 12:24:10 -06:00
|
|
|
if len(matches) == 0 {
|
|
|
|
return directoryPackageInfo{
|
|
|
|
status: directoryScanned,
|
|
|
|
err: fmt.Errorf("invalid module cache path: %v", subdir),
|
2019-10-09 17:05:30 -06:00
|
|
|
}
|
2019-09-04 12:24:10 -06:00
|
|
|
}
|
2019-08-02 12:05:22 -06:00
|
|
|
modPath, err := module.DecodePath(filepath.ToSlash(matches[1]))
|
|
|
|
if err != nil {
|
|
|
|
if r.env.Debug {
|
|
|
|
r.env.Logf("decoding module cache path %q: %v", subdir, err)
|
|
|
|
}
|
|
|
|
return directoryPackageInfo{
|
|
|
|
status: directoryScanned,
|
|
|
|
err: fmt.Errorf("decoding module cache path %q: %v", subdir, err),
|
2019-10-09 17:05:30 -06:00
|
|
|
}
|
2019-08-02 12:05:22 -06:00
|
|
|
}
|
|
|
|
importPath = path.Join(modPath, filepath.ToSlash(matches[3]))
|
|
|
|
}
|
|
|
|
|
2019-10-21 15:48:25 -06:00
|
|
|
modDir, modName := r.modInfo(dir)
|
2019-09-10 14:48:19 -06:00
|
|
|
result := directoryPackageInfo{
|
|
|
|
status: directoryScanned,
|
|
|
|
dir: dir,
|
2019-10-09 17:05:30 -06:00
|
|
|
rootType: root.Type,
|
2019-09-10 14:48:19 -06:00
|
|
|
nonCanonicalImportPath: importPath,
|
|
|
|
needsReplace: false,
|
2019-10-21 15:48:25 -06:00
|
|
|
moduleDir: modDir,
|
|
|
|
moduleName: modName,
|
2019-09-10 14:48:19 -06:00
|
|
|
}
|
|
|
|
if root.Type == gopathwalk.RootGOROOT {
|
|
|
|
// stdlib packages are always in scope, despite the confusing go.mod
|
2019-10-09 17:05:30 -06:00
|
|
|
return result
|
2019-09-10 14:48:19 -06:00
|
|
|
}
|
2019-08-02 12:05:22 -06:00
|
|
|
// Check that this package is not obviously impossible to import.
|
2019-10-21 15:48:25 -06:00
|
|
|
if !strings.HasPrefix(importPath, modName) {
|
2019-08-02 12:05:22 -06:00
|
|
|
// The module's declared path does not match
|
|
|
|
// its expected path. It probably needs a
|
|
|
|
// replace directive we don't have.
|
2019-09-10 14:48:19 -06:00
|
|
|
result.needsReplace = true
|
2019-08-02 12:05:22 -06:00
|
|
|
}
|
|
|
|
|
2019-10-09 17:05:30 -06:00
|
|
|
return result
|
2019-08-02 12:05:22 -06:00
|
|
|
}
|
|
|
|
|
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-16 14:24:49 -07:00
|
|
|
// modCacheRegexp splits a path in a module cache into module, module version, and package.
|
|
|
|
var modCacheRegexp = regexp.MustCompile(`(.*)@([^/\\]*)(.*)`)
|
|
|
|
|
|
|
|
var (
|
|
|
|
slashSlash = []byte("//")
|
|
|
|
moduleStr = []byte("module")
|
|
|
|
)
|
|
|
|
|
|
|
|
// modulePath returns the module path from the gomod file text.
|
|
|
|
// If it cannot find a module path, it returns an empty string.
|
|
|
|
// It is tolerant of unrelated problems in the go.mod file.
|
|
|
|
//
|
|
|
|
// Copied from cmd/go/internal/modfile.
|
|
|
|
func modulePath(mod []byte) string {
|
|
|
|
for len(mod) > 0 {
|
|
|
|
line := mod
|
|
|
|
mod = nil
|
|
|
|
if i := bytes.IndexByte(line, '\n'); i >= 0 {
|
|
|
|
line, mod = line[:i], line[i+1:]
|
|
|
|
}
|
|
|
|
if i := bytes.Index(line, slashSlash); i >= 0 {
|
|
|
|
line = line[:i]
|
|
|
|
}
|
|
|
|
line = bytes.TrimSpace(line)
|
|
|
|
if !bytes.HasPrefix(line, moduleStr) {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
line = line[len(moduleStr):]
|
|
|
|
n := len(line)
|
|
|
|
line = bytes.TrimSpace(line)
|
|
|
|
if len(line) == n || len(line) == 0 {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
if line[0] == '"' || line[0] == '`' {
|
|
|
|
p, err := strconv.Unquote(string(line))
|
|
|
|
if err != nil {
|
|
|
|
return "" // malformed quoted string or multiline module path
|
|
|
|
}
|
|
|
|
return p
|
|
|
|
}
|
|
|
|
|
|
|
|
return string(line)
|
|
|
|
}
|
|
|
|
return "" // missing module path
|
|
|
|
}
|
2019-10-23 15:36:29 -06:00
|
|
|
|
|
|
|
var modFlagRegexp = regexp.MustCompile(`-mod[ =](\w+)`)
|
|
|
|
|
|
|
|
// vendorEnabled indicates if vendoring is enabled.
|
|
|
|
// Inspired by setDefaultBuildMod in modload/init.go
|
|
|
|
func vendorEnabled(env *ProcessEnv) (*ModuleJSON, bool, error) {
|
|
|
|
mainMod, go114, err := getMainModuleAnd114(env)
|
|
|
|
if err != nil {
|
|
|
|
return nil, false, err
|
|
|
|
}
|
|
|
|
matches := modFlagRegexp.FindStringSubmatch(env.GOFLAGS)
|
|
|
|
var modFlag string
|
|
|
|
if len(matches) != 0 {
|
|
|
|
modFlag = matches[1]
|
|
|
|
}
|
|
|
|
if modFlag != "" {
|
|
|
|
// Don't override an explicit '-mod=' argument.
|
|
|
|
return mainMod, modFlag == "vendor", nil
|
|
|
|
}
|
|
|
|
if mainMod == nil || !go114 {
|
|
|
|
return mainMod, false, nil
|
|
|
|
}
|
|
|
|
// Check 1.14's automatic vendor mode.
|
|
|
|
if fi, err := os.Stat(filepath.Join(mainMod.Dir, "vendor")); err == nil && fi.IsDir() {
|
|
|
|
if mainMod.GoVersion != "" && semver.Compare("v"+mainMod.GoVersion, "v1.14") >= 0 {
|
|
|
|
// The Go version is at least 1.14, and a vendor directory exists.
|
|
|
|
// Set -mod=vendor by default.
|
|
|
|
return mainMod, true, nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return mainMod, false, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// getMainModuleAnd114 gets the main module's information and whether the
|
|
|
|
// go command in use is 1.14+. This is the information needed to figure out
|
|
|
|
// if vendoring should be enabled.
|
|
|
|
func getMainModuleAnd114(env *ProcessEnv) (*ModuleJSON, bool, error) {
|
|
|
|
const format = `{{.Path}}
|
|
|
|
{{.Dir}}
|
|
|
|
{{.GoMod}}
|
|
|
|
{{.GoVersion}}
|
|
|
|
{{range context.ReleaseTags}}{{if eq . "go1.14"}}{{.}}{{end}}{{end}}
|
|
|
|
`
|
|
|
|
stdout, err := env.invokeGo("list", "-m", "-f", format)
|
|
|
|
if err != nil {
|
|
|
|
return nil, false, nil
|
|
|
|
}
|
|
|
|
lines := strings.Split(stdout.String(), "\n")
|
|
|
|
if len(lines) < 5 {
|
|
|
|
return nil, false, fmt.Errorf("unexpected stdout: %q", stdout)
|
|
|
|
}
|
|
|
|
mod := &ModuleJSON{
|
|
|
|
Path: lines[0],
|
|
|
|
Dir: lines[1],
|
|
|
|
GoMod: lines[2],
|
|
|
|
GoVersion: lines[3],
|
|
|
|
Main: true,
|
|
|
|
}
|
|
|
|
return mod, lines[4] == "go1.14", nil
|
|
|
|
}
|