farzadmf commented 5 years ago

Update (after I created the original bug)

I noticed something: the issue that I have (details below) is happening when I open a folder inside of which one of the nested folders contains my go code, but when I directly open that go folder, things seem to be working fine. I don't know if this is the expected behavior or not

Describe the bug The tooling is "messed up" in a folder using go modules

VSCode settings This is the only go-related setting I have:

"go.useLanguageServer": true

To Reproduce Steps to reproduce the behavior:

Create a directory (e.g., test) outside of GOPATH
Go inside a directory and do go mod init test
Run go get -u github.com/spf13/cobra to get the cobra package
Run cobra init test to initialize a cobra application

Open cmd/root.go and you see an error about the cobra package:
Also, it doesn't recognize the other files in the same package; for example, here, rootCmd is defined in a sibling file with package cmd:

Expected behavior It should recognize the cobra package and provide IntelliSense for that

System information:

OS: Arch Linux (Manjaro)
Extension Version 0.11.7
VS Code Version 1.39.2

Additional context

I have run go: Install/Update Tools in VSCode and I have restarted VSCode
I don't think I had this problem before. It's been a while since I did something in go, and today, I'm confused. I don't know if it's something that I have changed on my computer, or there's something wrong with the extension, VSCode, etc. Maybe the only change that I can think of is that my GOPATH is on another file system /dev/sda4, mouted on /data, on I have export GOPATH=/data/manjaro-tools/go (and my home file system is on /dev/sda5, but I wouldn't expect that to have an effect on these things

Also, I can see cobra in my list of packages:


/data/manjaro-tools/go/pkg/mod/github.com/spf13
├── afero@v1.1.2
├── afero@v1.2.2
├── cast@v1.3.0
├── cobra@v0.0.0-20170417170307-b6cb39589372
├── cobra@v0.0.5
├── jwalterweatherman@v1.0.0
├── jwalterweatherman@v1.1.0
├── pflag@v0.0.0-20170417173400-9e4c21054fa1
├── pflag@v1.0.3
├── pflag@v1.0.5
├── viper@v1.3.2
└── viper@v1.4.0

12 directories, 0 files


Finally, I may add that I can run the application perfectly fine, so it seems that the tooling is confused.

stamblerre commented 5 years ago

What is the output of gopls -rpc.trace -v check path/to/file.go?

farzadmf commented 5 years ago

Thank you @stamblerre for your reply

Context: my actual go folder is located in /home/farzad/bin/my-system-files/mygo/mytool, and I run this command

gopls -rpc.trace -v check /home/farzad/bin/my-system-files/mygo/mytool/cmd/root.go

and the output seems to be different based on where I am:

Running from /home/farzad/bin/my-system-files/mygo/mytool:

2019/10/31 22:36:48 Info:2019/10/31 22:36:48 Build info
----------
golang.org/x/tools/gopls v0.1.7
    golang.org/x/tools/gopls@v0.1.7 h1:YwKf8t9h69++qCtVmc2q6fVuetFXmmu9LKoPMYLZid4=
    golang.org/x/sync@v0.0.0-20190423024810-112230192c58 h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU=
    golang.org/x/tools@v0.0.0-20190918214516-5a1a30219888 h1:ER45Jz0UDQ3e6em1lwXVwuPf96lvyQogb7m+gEbsoPg=
    golang.org/x/xerrors@v0.0.0-20190717185122-a985d3407aa7 h1:9zdDQZ7Thm29KFXgAX/+yaf3eVbP7djjWp/dXAppNCc=

Go info
-------
go version go1.13.3 linux/amd64

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/farzad/.cache/go-build"
GOENV="/home/farzad/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/data/manjaro-tools/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/farzad/bin/my-system-files/mygo/mytool/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-build701062425=/tmp/go-build -gno-record-gcc-switches"
2019/10/31 22:36:48 Info:2019/10/31 22:36:48 3.40095ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files/mygo/mytool go "env" "GOMOD", stderr: <<>>
2019/10/31 22:36:48 Info:2019/10/31 22:36:48 6.608795ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files/mygo/mytool go "list" "-e" "-json" "-compiled=true" "-test=true" "-export=false" "-deps=true" "-find=false" "--" "builtin", stderr: <<>>
2019/10/31 22:36:48 Info:2019/10/31 22:36:48 2.468822ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files/mygo/mytool go "env" "GOMOD", stderr: <<>>
2019/10/31 22:36:48 Info:2019/10/31 22:36:48 10.577376ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files/mygo/mytool go "list" "-m" "-json" "all", stderr: <<>>
2019/10/31 22:36:48 Info:2019/10/31 22:36:48 9.110841ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files/mygo/mytool go "list" "-m" "-json" "all", stderr: <<>>
2019/10/31 22:36:48 Info:2019/10/31 22:36:48 44.3325ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files/mygo/mytool go "list" "-e" "-json" "-compiled=true" "-test=true" "-export=false" "-deps=true" "-find=false" "--" "/home/farzad/bin/my-system-files/mygo/mytool/cmd", stderr: <<>>
2019/10/31 22:36:48 Info:2019/10/31 22:36:48 go/packages.Load
    packages = 1
2019/10/31 22:36:48 Info:2019/10/31 22:36:48 go/packages.Load
    package = mytool/cmd
    files = [/home/farzad/bin/my-system-files/mygo/mytool/cmd/root.go]

Running from /home/farzad/bin/my-system-files (which I think corresponds to how I get the errors because this is the folder that I open in VSCode and contains the go folder as a child):

2019/10/31 22:38:43 Info:2019/10/31 22:38:43 Build info
----------
golang.org/x/tools/gopls v0.1.7
    golang.org/x/tools/gopls@v0.1.7 h1:YwKf8t9h69++qCtVmc2q6fVuetFXmmu9LKoPMYLZid4=
    golang.org/x/sync@v0.0.0-20190423024810-112230192c58 h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU=
    golang.org/x/tools@v0.0.0-20190918214516-5a1a30219888 h1:ER45Jz0UDQ3e6em1lwXVwuPf96lvyQogb7m+gEbsoPg=
    golang.org/x/xerrors@v0.0.0-20190717185122-a985d3407aa7 h1:9zdDQZ7Thm29KFXgAX/+yaf3eVbP7djjWp/dXAppNCc=

Go info
-------
go version go1.13.3 linux/amd64

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/farzad/.cache/go-build"
GOENV="/home/farzad/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/data/manjaro-tools/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=""
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-build066152721=/tmp/go-build -gno-record-gcc-switches"
2019/10/31 22:38:43 Info:2019/10/31 22:38:43 2.32145ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files go "env" "GOMOD", stderr: <<>>
2019/10/31 22:38:43 Info:2019/10/31 22:38:43 3.050561ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files go "list" "-e" "-json" "-compiled=true" "-test=true" "-export=false" "-deps=true" "-find=false" "--" "builtin", stderr: <<>>
2019/10/31 22:38:43 Info:2019/10/31 22:38:43 3.220932ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files go "list" "-m" "-json" "all", stderr: <<go list -m: not using modules
>>
2019/10/31 22:38:43 Info:2019/10/31 22:38:43 2.276335ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files go "env" "GOPATH", stderr: <<>>
2019/10/31 22:38:43 Info:2019/10/31 22:38:43 2.013567ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files go "env" "GOMOD", stderr: <<>>
2019/10/31 22:38:43 Info:2019/10/31 22:38:43 2.680388ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files go "list" "-m" "-json" "all", stderr: <<go list -m: not using modules
>>
2019/10/31 22:38:43 Info:2019/10/31 22:38:43 2.052365ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files go "env" "GOPATH", stderr: <<>>
2019/10/31 22:38:43 Info:2019/10/31 22:38:43 2.486781ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files go "list" "-e" "-json" "-compiled=true" "-test=true" "-export=false" "-deps=true" "-find=false" "--" "/home/farzad/bin/my-system-files/mygo/mytool/cmd", stderr: <<>>
2019/10/31 22:38:43 Info:2019/10/31 22:38:43 35.987224ms for GOROOT= GOPATH=/data/manjaro-tools/go GO111MODULE= PWD=/home/farzad/bin/my-system-files go "list" "-e" "-json" "-compiled=true" "-test=true" "-export=false" "-deps=true" "-find=false" "--" "/home/farzad/bin/my-system-files/mygo/mytool/cmd/root.go", stderr: <<>>
2019/10/31 22:38:43 Info:2019/10/31 22:38:43 go/packages.Load
    packages = 1
2019/10/31 22:38:43 Info:2019/10/31 22:38:43 go/packages.Load
    package = command-line-arguments
    files = [/home/farzad/bin/my-system-files/mygo/mytool/cmd/root.go]
/home/farzad/bin/my-system-files/mygo/mytool/cmd/root.go:7:2-26: could not import github.com/spf13/cobra (no package data for import path github.com/spf13/cobra)

stamblerre commented 5 years ago

Yeah, with modules, gopls requires that you open your VSCode window at the module root (the directory containing the go.mod file).

farzadmf commented 5 years ago

I guess it has something to do with this issue golang/go#32394, am I right?

stamblerre commented 5 years ago

Yes, exactly.

farzadmf commented 5 years ago

Thank you @stamblerre , so I'll close this as this is not applicable unless that one's fixed.

Also, while I have you here 😝, can I bother you with another question:

I have a Linux development environment, and I wanted to code something for Windows using npipe package. It turns out that the package is "windows-only" (all the files have _windows suffix), and when I'm coding against that, I get no support whatsoever in VSCode (it does NOT complain about the import, but when I for example do F12 to go to package, it says "no definition found"):

I've also suffixed my file with _windows, so do you think the issue here is also with gopls? (the issue golang/tools#29202 maybe?). Is the file suffix also considered to be similar to build tags covered by the issue?

stamblerre commented 4 years ago

Yes, that is another known issue: https://github.com/golang/go/issues/29202.

microsoft / vscode-go

Tooling "messed up" when using the `cobra` package #2866

Update (after I created the original bug)