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"
|
|
|
|
|
|
|
|
"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-12-30 11:29:41 -07:00
|
|
|
env *ProcessEnv
|
|
|
|
moduleCacheDir string
|
|
|
|
dummyVendorMod *ModuleJSON // If vendoring is enabled, the pseudo-module that represents the /vendor directory.
|
|
|
|
roots []gopathwalk.Root
|
2020-01-02 14:10:45 -07:00
|
|
|
scanSema chan struct{} // scanSema prevents concurrent scans and guards scannedRoots.
|
2019-12-30 11:29:41 -07:00
|
|
|
scannedRoots map[gopathwalk.Root]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
|
|
|
|
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?
|
2019-12-18 17:08:00 -07:00
|
|
|
Indirect bool // is this module only an indirect dependency of main module?
|
2019-10-23 15:36:29 -06:00
|
|
|
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-12-27 16:25:19 -07:00
|
|
|
r.roots = []gopathwalk.Root{
|
|
|
|
{filepath.Join(r.env.GOROOT, "/src"), gopathwalk.RootGOROOT},
|
|
|
|
}
|
|
|
|
if r.Main != nil {
|
|
|
|
r.roots = append(r.roots, gopathwalk.Root{r.Main.Dir, gopathwalk.RootCurrentModule})
|
|
|
|
}
|
|
|
|
if vendorEnabled {
|
|
|
|
r.roots = append(r.roots, gopathwalk.Root{r.dummyVendorMod.Dir, gopathwalk.RootOther})
|
|
|
|
} else {
|
|
|
|
addDep := func(mod *ModuleJSON) {
|
|
|
|
if mod.Replace == nil {
|
|
|
|
// This is redundant with the cache, but we'll skip it cheaply enough.
|
|
|
|
r.roots = append(r.roots, gopathwalk.Root{mod.Dir, gopathwalk.RootModuleCache})
|
|
|
|
} else {
|
|
|
|
r.roots = append(r.roots, gopathwalk.Root{mod.Dir, gopathwalk.RootOther})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// Walk dependent modules before scanning the full mod cache, direct deps first.
|
|
|
|
for _, mod := range r.ModsByModPath {
|
2020-01-02 14:10:45 -07:00
|
|
|
if !mod.Indirect && !mod.Main {
|
2019-12-27 16:25:19 -07:00
|
|
|
addDep(mod)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
for _, mod := range r.ModsByModPath {
|
2020-01-02 14:10:45 -07:00
|
|
|
if mod.Indirect && !mod.Main {
|
2019-12-27 16:25:19 -07:00
|
|
|
addDep(mod)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
r.roots = append(r.roots, gopathwalk.Root{r.moduleCacheDir, gopathwalk.RootModuleCache})
|
|
|
|
}
|
|
|
|
|
2019-12-30 11:29:41 -07:00
|
|
|
r.scannedRoots = map[gopathwalk.Root]bool{}
|
2020-01-02 14:10:45 -07:00
|
|
|
if r.scanSema == nil {
|
|
|
|
r.scanSema = make(chan struct{}, 1)
|
|
|
|
r.scanSema <- struct{}{}
|
|
|
|
}
|
2019-10-09 17:05:30 -06:00
|
|
|
if r.moduleCacheCache == nil {
|
|
|
|
r.moduleCacheCache = &dirInfoCache{
|
2020-01-02 14:10:45 -07:00
|
|
|
dirs: map[string]*directoryPackageInfo{},
|
|
|
|
listeners: map[*int]cacheListener{},
|
2019-10-09 17:05:30 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if r.otherCache == nil {
|
|
|
|
r.otherCache = &dirInfoCache{
|
2020-01-02 14:10:45 -07:00
|
|
|
dirs: map[string]*directoryPackageInfo{},
|
|
|
|
listeners: map[*int]cacheListener{},
|
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() {
|
2020-01-02 14:10:45 -07:00
|
|
|
<-r.scanSema
|
2019-12-30 11:29:41 -07:00
|
|
|
r.scannedRoots = map[gopathwalk.Root]bool{}
|
2019-10-09 17:05:30 -06:00
|
|
|
r.otherCache = &dirInfoCache{
|
|
|
|
dirs: map[string]*directoryPackageInfo{},
|
|
|
|
}
|
2020-01-02 14:10:45 -07:00
|
|
|
r.scanSema <- struct{}{}
|
2019-10-09 17:05:30 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func (r *ModuleResolver) ClearForNewMod() {
|
2020-01-02 14:10:45 -07:00
|
|
|
<-r.scanSema
|
2019-10-09 17:05:30 -06:00
|
|
|
*r = ModuleResolver{
|
2020-01-02 14:10:45 -07:00
|
|
|
env: r.env,
|
|
|
|
moduleCacheCache: r.moduleCacheCache,
|
|
|
|
otherCache: r.otherCache,
|
|
|
|
scanSema: r.scanSema,
|
2019-10-09 17:05:30 -06:00
|
|
|
}
|
|
|
|
r.init()
|
2020-01-02 14:10:45 -07:00
|
|
|
r.scanSema <- struct{}{}
|
2019-10-09 17:05:30 -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
|
|
|
// 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.
|
2019-11-04 12:02:48 -07:00
|
|
|
if _, err := r.cachePackageName(info); err == nil {
|
2019-10-09 17:05:30 -06:00
|
|
|
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.
|
2019-12-26 17:13:58 -07:00
|
|
|
func (r *ModuleResolver) cachePackageName(info directoryPackageInfo) (string, error) {
|
2019-11-04 12:02:48 -07:00
|
|
|
if info.rootType == gopathwalk.RootModuleCache {
|
|
|
|
return r.moduleCacheCache.CachePackageName(info)
|
2019-10-09 17:05:30 -06:00
|
|
|
}
|
2019-11-04 12:02:48 -07:00
|
|
|
return r.otherCache.CachePackageName(info)
|
|
|
|
}
|
2019-10-09 17:05:30 -06:00
|
|
|
|
2019-11-04 12:02:48 -07:00
|
|
|
func (r *ModuleResolver) cacheExports(ctx context.Context, env *ProcessEnv, info directoryPackageInfo) (string, []string, error) {
|
|
|
|
if info.rootType == gopathwalk.RootModuleCache {
|
|
|
|
return r.moduleCacheCache.CacheExports(ctx, env, info)
|
2019-10-09 17:05:30 -06:00
|
|
|
}
|
2019-11-04 12:02:48 -07:00
|
|
|
return r.otherCache.CacheExports(ctx, env, info)
|
2019-10-09 17:05:30 -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
|
|
|
// 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-12-30 11:29:41 -07:00
|
|
|
func (r *ModuleResolver) scan(ctx context.Context, callback *scanCallback) 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 {
|
2019-12-26 17:13:58 -07:00
|
|
|
return 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
|
|
|
}
|
|
|
|
|
2019-12-27 16:25:19 -07:00
|
|
|
processDir := func(info directoryPackageInfo) {
|
|
|
|
// Skip this directory if we were not able to get the package information successfully.
|
|
|
|
if scanned, err := info.reachedStatus(directoryScanned); !scanned || err != nil {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
pkg, err := r.canonicalize(info)
|
|
|
|
if err != nil {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2020-01-02 14:04:45 -07:00
|
|
|
if !callback.dirFound(pkg) {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
pkg.packageName, err = r.cachePackageName(info)
|
|
|
|
if err != nil {
|
|
|
|
return
|
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-12-27 16:25:19 -07:00
|
|
|
|
2020-01-02 14:04:45 -07:00
|
|
|
if !callback.packageNameLoaded(pkg) {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
_, exports, err := r.loadExports(ctx, pkg)
|
|
|
|
if err != nil {
|
|
|
|
return
|
2019-12-27 16:25:19 -07:00
|
|
|
}
|
2020-01-02 14:04:45 -07:00
|
|
|
callback.exportsLoaded(pkg, exports)
|
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
|
|
|
}
|
|
|
|
|
2020-01-02 14:10:45 -07:00
|
|
|
// Start processing everything in the cache, and listen for the new stuff
|
|
|
|
// we discover in the walk below.
|
|
|
|
stop1 := r.moduleCacheCache.ScanAndListen(ctx, processDir)
|
|
|
|
defer stop1()
|
|
|
|
stop2 := r.otherCache.ScanAndListen(ctx, processDir)
|
|
|
|
defer stop2()
|
2019-10-04 13:38:18 -06:00
|
|
|
|
2019-12-27 16:25:19 -07:00
|
|
|
// We assume cached directories are fully cached, including all their
|
|
|
|
// children, and have not changed. We can skip them.
|
2019-07-19 10:41:29 -06:00
|
|
|
skip := func(root gopathwalk.Root, dir string) bool {
|
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
|
|
|
|
2020-01-02 14:10:45 -07:00
|
|
|
// Add anything new to the cache, and process it if we're still listening.
|
2019-07-19 10:41:29 -06:00
|
|
|
add := func(root gopathwalk.Root, dir string) {
|
2020-01-02 14:10:45 -07:00
|
|
|
r.cacheStore(r.scanDirForPackage(root, dir))
|
2019-12-27 16:25:19 -07:00
|
|
|
}
|
2019-12-26 17:13:58 -07:00
|
|
|
|
2020-01-02 14:10:45 -07:00
|
|
|
// r.roots and the callback are not necessarily safe to use in the
|
|
|
|
// goroutine below. Process them eagerly.
|
|
|
|
roots := filterRoots(r.roots, callback.rootFound)
|
2019-12-27 16:25:19 -07:00
|
|
|
// We can't cancel walks, because we need them to finish to have a usable
|
2020-01-02 14:10:45 -07:00
|
|
|
// cache. Instead, run them in a separate goroutine and detach.
|
|
|
|
scanDone := make(chan struct{})
|
|
|
|
go func() {
|
|
|
|
select {
|
|
|
|
case <-ctx.Done():
|
|
|
|
return
|
|
|
|
case <-r.scanSema:
|
2019-07-19 10:41:29 -06:00
|
|
|
}
|
2020-01-02 14:10:45 -07:00
|
|
|
defer func() { r.scanSema <- struct{}{} }()
|
|
|
|
// We have the lock on r.scannedRoots, and no other scans can run.
|
|
|
|
for _, root := range roots {
|
|
|
|
if ctx.Err() != nil {
|
|
|
|
return
|
|
|
|
}
|
2019-12-30 11:29:41 -07:00
|
|
|
|
2020-01-02 14:10:45 -07:00
|
|
|
if r.scannedRoots[root] {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
gopathwalk.WalkSkip([]gopathwalk.Root{root}, add, skip, gopathwalk.Options{Debug: r.env.Debug, ModulesEnabled: true})
|
|
|
|
r.scannedRoots[root] = true
|
|
|
|
}
|
|
|
|
close(scanDone)
|
|
|
|
}()
|
|
|
|
select {
|
|
|
|
case <-ctx.Done():
|
|
|
|
case <-scanDone:
|
2019-07-19 10:41:29 -06:00
|
|
|
}
|
2019-12-26 17:13:58 -07:00
|
|
|
return nil
|
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
|
|
|
// 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-12-27 13:46:49 -07:00
|
|
|
relevance: MaxRelevance,
|
2019-09-12 14:41:22 -06:00
|
|
|
}, nil
|
|
|
|
}
|
|
|
|
|
2019-10-04 13:38:18 -06:00
|
|
|
importPath := info.nonCanonicalImportPath
|
2019-12-27 13:46:49 -07:00
|
|
|
relevance := MaxRelevance - 3
|
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-12-18 17:08:00 -07:00
|
|
|
if mod.Indirect {
|
2019-12-27 13:46:49 -07:00
|
|
|
relevance = MaxRelevance - 2
|
2019-12-18 17:08:00 -07:00
|
|
|
} else {
|
2019-12-27 13:46:49 -07:00
|
|
|
relevance = MaxRelevance - 1
|
2019-12-18 17:08:00 -07:00
|
|
|
}
|
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-12-30 11:30:09 -07:00
|
|
|
} else if !strings.HasPrefix(importPath, info.moduleName) {
|
|
|
|
// The module's name doesn't match the package's import path. It
|
|
|
|
// probably needs a replace directive we don't have.
|
2019-10-04 13:38:18 -06:00
|
|
|
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,
|
2019-10-30 14:59:29 -06:00
|
|
|
relevance: relevance,
|
2019-10-04 13:38:18 -06:00
|
|
|
}
|
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-11-04 12:02:48 -07:00
|
|
|
func (r *ModuleResolver) loadExports(ctx context.Context, pkg *pkg) (string, []string, error) {
|
2019-08-02 11:04:42 -06:00
|
|
|
if err := r.init(); err != nil {
|
2019-11-04 12:02:48 -07:00
|
|
|
return "", nil, err
|
|
|
|
}
|
|
|
|
if info, ok := r.cacheLoad(pkg.dir); ok {
|
|
|
|
return r.cacheExports(ctx, r.env, info)
|
2019-08-02 11:04:42 -06:00
|
|
|
}
|
2019-11-04 12:02:48 -07:00
|
|
|
return loadExportsFromFiles(ctx, r.env, pkg.dir)
|
2019-08-02 11:04:42 -06:00
|
|
|
}
|
|
|
|
|
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,
|
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-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
|
|
|
|
}
|