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.

Sign up for GitHub

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

Jump to bottom

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
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
gopls/v0.3.0

Comments

@zikaeroh
Copy link
Contributor

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
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels 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
Copy link
Contributor

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

@stamblerre
Copy link
Contributor

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
@stamblerre
go/packages: handle an overlay edge case with test variants
593de60 
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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

stamblerre commented Jan 24, 2020 •
edited
Loading

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
		}
	]
}

@heschi
Copy link
Contributor

heschi 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
Copy link
Contributor

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

@gopherbot
Copy link
Contributor

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

@stamblerre stamblerre mentioned this issue Jan 24, 2020
Closed
@golang golang locked and limited conversation to collaborators Jan 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
gopls/v0.3.0
Development

No branches or pull requests
4 participants
@stamblerre @gopherbot @heschi @zikaeroh