Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: "could not import ___" after adding new _test package #36635

Closed
zikaeroh opened this issue Jan 18, 2020 · 8 comments
Closed

x/tools/gopls: "could not import ___" after adding new _test package #36635

zikaeroh opened this issue Jan 18, 2020 · 8 comments
Labels
Milestone

Comments

@zikaeroh
Copy link

@zikaeroh zikaeroh commented Jan 18, 2020

Please answer these questions before submitting your issue. Thanks!

What did you do?

I created a package, added code to it, then added a _test package to the same directory.

What did you expect to see?

No errors, I can start working on that package.

What did you see instead?

On finishing typing my package name, all of the imports in my non-test code had "could not import" errors.

Logs: https://gist.github.com/zikaeroh/6ba035d30a5493e19e8673b47ace4f7c

Build info

golang.org/x/tools/gopls master
    golang.org/x/tools/gopls@v0.1.8-0.20200117220505-0cba7a3a9ee9 h1:nzvuLbmeJ+AcY2QpRizKDzip5dbZHStOlteBZR29PH8=
    github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/sergi/go-diff@v1.0.0 h1:Kpca3qRNrduNnOQeazBd0ysaKrUJiIuISHxogkT9RPQ=
    golang.org/x/mod@v0.1.1-0.20191105210325-c90efee705ee h1:WG0RUwxtNT4qqaXX3DPA8zHFNm/D9xaBpxzHt1WcA/E=
    golang.org/x/sync@v0.0.0-20190423024810-112230192c58 h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU=
    golang.org/x/tools@v0.0.0-20200117220505-0cba7a3a9ee9 h1:KOkk4e2xd5OeCDJGwacvr75ICCbCsShrHiqPEdsA9hg=
    golang.org/x/xerrors@v0.0.0-20191011141410-1b5146add898 h1:/atklqdjdhuosWIl6AIbOeHJjicWYPqR9bpxqxYG2pA=
    honnef.co/go/tools@v0.0.1-2019.2.3 h1:3JgtbtFHMiCmsznwGVTUWbgGov+pVqnlf1dEJTNAXeM=
    mvdan.cc/xurls/v2@v2.1.0 h1:KaMb5GLhlcSX+e+qhbRJODnUUBvlw01jt4yrjFIHAuA=

Go info

go version go1.13.6 linux/amd64

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jake/.cache/go-build"
GOENV="/home/jake/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jake/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jake/zikaeroh/hortbot/hortbot/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build755509892=/tmp/go-build -gno-record-gcc-switches"
@gopherbot gopherbot added this to the Unreleased milestone Jan 18, 2020
@stamblerre stamblerre modified the milestones: Unreleased, gopls/v0.3.0 Jan 21, 2020
@golang golang deleted a comment from gopherbot Jan 21, 2020
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jan 22, 2020

Change https://golang.org/cl/215743 mentions this issue: go/packages: handle an overlay edge case with test variants

@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Jan 22, 2020

This sounds exactly like #35949, so we will have to be careful to not make the same mistakes here. Go 1.14 will have the fix for #35973, which should help things a little.

gopherbot pushed a commit to golang/tools that referenced this issue Jan 23, 2020
As usual, in debugging the creation of a new file with gopls, I've
encountered a go/packages overlay bug. The issue is:

A file b/b.go with package name "b" exists on disk. A package
b/b_test.go with no content exists on disk. There is an overlay for
b/b_test.go that contains the package name "b". Running packages.Load
for file=b/b_test.go will result in a failure to load package b
[b.test]. This change adds this test to the go/packages tests.

This case is fixed by restricting the fallback logic in
runContainsQueries. We only attempt to construct an ad-hoc package if
the original package was returned with no GoFiles.

Also, a minor change to the gopls error parsing code that fixes a case
in which diagnostics were being sent without corresponding files.

Updates golang/go#36635.

Change-Id: I38680a2cc65ae9c3252294db6b942d031189faf5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/215743
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Jan 23, 2020

This issue is a combination of #35973 and #36661. With Go 1.14, the imports no longer disappear, since that fix is available there. The fact that we don't recover from the imports disappearing can be attributed to this fact (#36661 (comment)):

The problem here is that the initial workspace load finds nothing, and AFAIK we currently have no mechanism for adding packages to the workspace set, so they don't ever end up getting diagnosed in the background.

I will then close this issue and continue work on modifying the workspace packages set on #36661.

@stamblerre stamblerre closed this Jan 23, 2020
@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Jan 24, 2020

On the further investigation, the issue persists apart from what #36661 covers. I will keep investigating, but as it already existed in gopls/v0.2.2, I will move it out of the gopls/v0.3.0 milestone.

@stamblerre stamblerre reopened this Jan 24, 2020
@stamblerre stamblerre modified the milestones: gopls/v0.3.0, gopls/v1.0.0 Jan 24, 2020
@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Jan 24, 2020

The main issue here is that these tests in go/packages pass, but creating the same file structure in gopls fails. To repro (with Go 1.14), create a module containing only a non-test file with some dependency. For example:

package bad

import "fmt"

func hello() {
    fmt.Println("hello")
}

Then, create the corresponding test file in VS Code. It will be prepopulated if you create it through the VS Code UI. Running go/packages on this file will not give you the same result, as expected in that test.

/cc @heschik

Also worth noting that running the gopackages command outputs a package with command-line-arguments:

gopackages -json -deps -test ~/bad/bad_test.go 
{
	"ID": "command-line-arguments",
	"PkgPath": "command-line-arguments",
	"Errors": [
		{
			"Pos": "",
			"Msg": "bad_test.go:1:1: expected 'package', found 'EOF'",
			"Kind": 1
		}
	]
}
@heschik

This comment has been minimized.

Copy link
Contributor

@heschik heschik commented Jan 24, 2020

I believe the problem is that packages.Load("./...") does not return the overlay packages.

@stamblerre stamblerre modified the milestones: gopls/v1.0.0, gopls/v0.3.0 Jan 24, 2020
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jan 24, 2020

Change https://golang.org/cl/216141 mentions this issue: internal/lsp: track orphaned files when a file is created

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jan 24, 2020

Change https://golang.org/cl/216141 mentions this issue: internal/lsp: reload metadata for orphaned files

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.