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/cmd/gopls: support for module mode without go.mod #31837

Closed
bhcleek opened this issue May 4, 2019 · 8 comments
Closed

x/tools/cmd/gopls: support for module mode without go.mod #31837

bhcleek opened this issue May 4, 2019 · 8 comments

Comments

@bhcleek
Copy link
Contributor

@bhcleek bhcleek commented May 4, 2019

What version of Go are you using (go version)?

go version go1.12.4 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOBIN="/Users/bhcleek/go/bin"
GOCACHE="/Users/bhcleek/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/bhcleek/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/f9/d6g779t53gq_20w0zm2f_1zm0000gn/T/go-build154198227=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Attempted to use gopls in a directory that is not in $GOPATH and is without a go.mod file.

A file to test with:

package main

import "fmt"

func main() {
	fmt.Println("vim-go")
}

And a simple test case:

❯❯❯ gopls query definition /Users/bhcleek/foo.go:#48
definition: /Users/bhcleek/foo.go:#48: no file information for file:///Users/bhcleek/foo.go

What did you expect to see?

Generally, I expected it to work, because the release notes for Go 1.12 state explicitly in https://golang.org/doc/go1.12#modules:

When GO111MODULE is set to on, the go command now supports module-aware operations outside of a module directory, provided that those operations do not need to resolve import paths relative to the current directory or explicitly edit the go.mod file. Commands such as go get, go list, and go mod download behave as if in a module with initially-empty requirements. In this mode, go env GOMOD reports the system's null device (/dev/null or NUL).

Using the simple test case provided above, I would expect the output to be

/usr/local/go/src/fmt/print.go:274:6-13: defined here as func fmt.Println(a ...interface{}) (n int, err error)

What did you see instead?

When run as a server, gopls claims that that there's no information known about the file.

The simple test case provided above outputs:

definition: file:///Users/bhcleek/foo.go: open /Users/bhcleek/foo.go: no such file or directory
@gopherbot gopherbot added this to the Unreleased milestone May 4, 2019
@gopherbot gopherbot added the gopls label May 4, 2019
@ianthehat
Copy link

@ianthehat ianthehat commented May 6, 2019

This is not going to be changed, sorry,
gopls specifically falls into the "need to resolve import paths relative to the current directory" category.
It never tries to guess a working directory based on the input files, you have to be explicit.

server mode is not supported at all, it is a pure debugging aid, but when it does work we will only support the command line adding a new view to the server based on its current working directory, which means where you launch the server from will not matter, but where you launch the client from still will.

@ianthehat ianthehat closed this May 6, 2019
@bhcleek
Copy link
Contributor Author

@bhcleek bhcleek commented May 9, 2019

I understand that gopls needs to have an explicit working directory, and I'm not proposing to remove that expectation. In the case when a package has no relative imports and neither has an explicit go.mod nor is in GOPATH, allowing editors to rely on gopls to provide users' the experience they expect (especially given that go build, go list, etc. work) would be valuable for editors that provide features using gopls. This typically comes up when a user has a go runnable package that they want to edit using vim-go, vscode, et al.

Sorry, I didn't mean literally the server mode of gopls that's used for debugging; I just meant the usual mode used by editors as opposed to gopls query.

No worries if the answer is still never, but I wanted to make sure I laid out the use case better.

@stevanmilic
Copy link

@stevanmilic stevanmilic commented May 13, 2019

I didn't have any idea that go. mod is a required file in order for gopls to work.
I think we should at least have it stated in the gopls docs.

@bhcleek Thanks for pointing that out!

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 13, 2019

gopls does not require a go.mod file to work. If you do not have a go.mod file, you will need to be in a directory in your $GOPATH.

@stevanmilic
Copy link

@stevanmilic stevanmilic commented May 13, 2019

Yea, I'm aware of that, but I wanted to edit files in a directory that is not in $GOPATH.
I'm a Vim user, and I wanted to edit some random test.go file in home directory, and I'm seeing the error but I don't understand what the problem is.
All other plugins I came across work perfectly without $GOPATH directory and go.mod file.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 13, 2019

gopls relies on the behavior of go list to understand how to type-check the package correctly. If go list fails in a given directory, we avoid making guesses for the sake of correctness. This could potentially be a nice feature, but I don't think it's something we will consider supporting in the near future.

@stevanmilic
Copy link

@stevanmilic stevanmilic commented May 13, 2019

Sure, I'm not saying you have to. It would just be helpful if that's written in the docs.

@bhcleek
Copy link
Contributor Author

@bhcleek bhcleek commented May 14, 2019

@stamblerre what is it about go list that gopls needs but isn't provided in this case (it exits 0 and provides info about the package)?

#! /bin/bash

cd $(mktemp -d)

cat <<EOF > main.go
package main

import "fmt"

func main() {
	fmt.Println("Go, please")
}
EOF

go list -json .
@golang golang locked and limited conversation to collaborators May 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

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