2020-05-09 06:54:23 -06:00
|
|
|
package regtest
|
|
|
|
|
|
|
|
import (
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
"io/ioutil"
|
|
|
|
"os"
|
|
|
|
"path/filepath"
|
|
|
|
"strings"
|
2020-05-09 06:54:23 -06:00
|
|
|
"testing"
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
|
|
|
|
"golang.org/x/tools/internal/lsp/fake"
|
|
|
|
"golang.org/x/tools/internal/testenv"
|
2020-05-09 06:54:23 -06:00
|
|
|
)
|
|
|
|
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
func TestIssue38815(t *testing.T) {
|
|
|
|
const needs = `
|
2020-05-09 06:54:23 -06:00
|
|
|
-- go.mod --
|
|
|
|
module foo
|
|
|
|
|
|
|
|
-- a.go --
|
|
|
|
package main
|
|
|
|
func f() {}
|
|
|
|
`
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
const ntest = `package main
|
2020-05-09 06:54:23 -06:00
|
|
|
func TestZ(t *testing.T) {
|
|
|
|
f()
|
|
|
|
}
|
|
|
|
`
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
const want = `package main
|
2020-05-09 06:54:23 -06:00
|
|
|
|
|
|
|
import "testing"
|
|
|
|
|
|
|
|
func TestZ(t *testing.T) {
|
|
|
|
f()
|
|
|
|
}
|
|
|
|
`
|
|
|
|
|
|
|
|
// it was returning
|
|
|
|
// "package main\nimport \"testing\"\npackage main..."
|
|
|
|
runner.Run(t, needs, func(t *testing.T, env *Env) {
|
|
|
|
env.CreateBuffer("a_test.go", ntest)
|
|
|
|
env.SaveBuffer("a_test.go")
|
|
|
|
got := env.Editor.BufferText("a_test.go")
|
|
|
|
if want != got {
|
|
|
|
t.Errorf("got\n%q, wanted\n%q", got, want)
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
func TestVim1(t *testing.T) {
|
|
|
|
const vim1 = `package main
|
2020-05-09 06:54:23 -06:00
|
|
|
|
|
|
|
import "fmt"
|
|
|
|
|
|
|
|
var foo = 1
|
|
|
|
var bar = 2
|
|
|
|
|
|
|
|
func main() {
|
|
|
|
fmt.Printf("This is a test %v\n", foo)
|
|
|
|
fmt.Printf("This is another test %v\n", foo)
|
|
|
|
fmt.Printf("This is also a test %v\n", foo)
|
|
|
|
}
|
|
|
|
`
|
|
|
|
|
|
|
|
// The file remains unchanged, but if there are any CodeActions returned, they confuse vim.
|
|
|
|
// Therefore check for no CodeActions
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
runner.Run(t, "", func(t *testing.T, env *Env) {
|
2020-05-09 06:54:23 -06:00
|
|
|
env.CreateBuffer("main.go", vim1)
|
|
|
|
env.OrganizeImports("main.go")
|
|
|
|
actions := env.CodeAction("main.go")
|
|
|
|
if len(actions) > 0 {
|
|
|
|
got := env.Editor.BufferText("main.go")
|
|
|
|
t.Errorf("unexpected actions %#v", actions)
|
|
|
|
if got == vim1 {
|
|
|
|
t.Errorf("no changes")
|
|
|
|
} else {
|
|
|
|
t.Errorf("got\n%q", got)
|
|
|
|
t.Errorf("was\n%q", vim1)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
func TestVim2(t *testing.T) {
|
|
|
|
const vim2 = `package main
|
2020-05-09 06:54:23 -06:00
|
|
|
|
|
|
|
import (
|
|
|
|
"fmt"
|
|
|
|
|
|
|
|
"example.com/blah"
|
|
|
|
|
|
|
|
"rubbish.com/useless"
|
|
|
|
)
|
|
|
|
|
|
|
|
func main() {
|
|
|
|
fmt.Println(blah.Name, useless.Name)
|
|
|
|
}
|
|
|
|
`
|
|
|
|
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
runner.Run(t, "", func(t *testing.T, env *Env) {
|
2020-05-09 06:54:23 -06:00
|
|
|
env.CreateBuffer("main.go", vim2)
|
|
|
|
env.OrganizeImports("main.go")
|
|
|
|
actions := env.CodeAction("main.go")
|
|
|
|
if len(actions) > 0 {
|
|
|
|
t.Errorf("unexpected actions %#v", actions)
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
|
|
|
|
func TestGOMODCACHE(t *testing.T) {
|
|
|
|
const proxy = `
|
|
|
|
-- example.com@v1.2.3/go.mod --
|
|
|
|
module example.com
|
|
|
|
|
|
|
|
go 1.12
|
|
|
|
-- example.com@v1.2.3/x/x.go --
|
|
|
|
package x
|
|
|
|
|
|
|
|
const X = 1
|
|
|
|
-- example.com@v1.2.3/y/y.go --
|
|
|
|
package y
|
|
|
|
|
|
|
|
const Y = 2
|
|
|
|
`
|
2020-07-22 12:03:48 -06:00
|
|
|
const files = `
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
-- go.mod --
|
|
|
|
module mod.com
|
|
|
|
|
|
|
|
require example.com v1.2.3
|
|
|
|
|
|
|
|
-- main.go --
|
|
|
|
package main
|
|
|
|
|
|
|
|
import "example.com/x"
|
|
|
|
|
|
|
|
var _, _ = x.X, y.Y
|
|
|
|
`
|
|
|
|
testenv.NeedsGo1Point(t, 15)
|
|
|
|
|
|
|
|
modcache, err := ioutil.TempDir("", "TestGOMODCACHE-modcache")
|
|
|
|
if err != nil {
|
|
|
|
t.Fatal(err)
|
|
|
|
}
|
|
|
|
defer os.RemoveAll(modcache)
|
2020-07-22 12:03:48 -06:00
|
|
|
editorConfig := fake.EditorConfig{Env: map[string]string{"GOMODCACHE": modcache}}
|
|
|
|
withOptions(
|
|
|
|
WithEditorConfig(editorConfig),
|
|
|
|
WithProxy(proxy),
|
|
|
|
).run(t, files, func(t *testing.T, env *Env) {
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
env.OpenFile("main.go")
|
|
|
|
env.Await(env.DiagnosticAtRegexp("main.go", `y.Y`))
|
|
|
|
env.SaveBuffer("main.go")
|
|
|
|
env.Await(EmptyDiagnostics("main.go"))
|
|
|
|
path, _ := env.GoToDefinition("main.go", env.RegexpSearch("main.go", `y.(Y)`))
|
|
|
|
if !strings.HasPrefix(path, filepath.ToSlash(modcache)) {
|
|
|
|
t.Errorf("found module dependency outside of GOMODCACHE: got %v, wanted subdir of %v", path, filepath.ToSlash(modcache))
|
|
|
|
}
|
2020-07-22 12:03:48 -06:00
|
|
|
})
|
all: rework goimports environment, support GOMODCACHE
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixes golang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-06-23 12:44:42 -06:00
|
|
|
}
|