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

Jump to bottom

x/tools/gopls: whether or not the files are under git affects gopls's behaviour? #38582

Closed
zbelial opened this issue Apr 22, 2020 · 5 comments
Closed

x/tools/gopls: whether or not the files are under git affects gopls's behaviour? #38582

zbelial opened this issue Apr 22, 2020 · 5 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. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
gopls/v0.4.1

Comments

@zbelial
Copy link

zbelial commented Apr 22, 2020

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

$ go version
go version go1.14 linux/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
GO111MODULE=""
GOARCH="amd64"
GOBIN="/mnt/Personal/Bin/go-tools"
GOCACHE="/home/lucency/.cache/go-build"
GOENV="/home/lucency/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/lucency/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/mnt/Personal/Bin/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/mnt/Personal/Bin/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-build444708836=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I use Emacs 27 + eglot.
I want to use another module in a module and I want to put all files under a git repo.

  1. Suppose you're in a directory D, which is not a git repo NOW.
  2. Follow the Working Example in the accepted answer in the next link. When you finish and open osinf.go, things(I mean go to definition, hover and completion) work well.
    so link
  3. Close osinf.go and exit Emacs.
  4. Execute git init . && git add . in diretory D.
  5. Reopen osinf.go, things do not work now.

What did you expect to see?

Go to definition, completion work as expected.

What did you see instead?

You are neither in a module nor in your GOPATH.

Other

It seems that when files are under git, gopls will take that into account and ignore(?) go.mod in some degree.
Is this the expected behaviour? If so, is there any way to work around it?

Thanks.
@gopherbot gopherbot added this to the Unreleased milestone Apr 22, 2020
@gopherbot
Copy link

Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

@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 Apr 22, 2020
@stamblerre stamblerre modified the milestones: Unreleased, gopls/v0.5.0 Apr 22, 2020
@stamblerre
Copy link
Contributor

Whether or not the files are tracked in git should have no effect on the functionality of gopls. Can you please provide gopls logs where you are seeing this behavior?

@stamblerre stamblerre added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Apr 22, 2020
@zbelial
Copy link
Author

zbelial commented Apr 23, 2020

Hi @stamblerre , thanks for you reply.

  1. Sorry that I've not found how to get gopls logs now. I tried to use gopls serve -logfile $HOME/gopls.log to start gopls in Emacs, but gopls.log was empty. But
  2. I found something else.
    Suppose the following is the dir layout.
D
├── osinf
│   ├── go.mod
│   └── osinf.go
└── pretty
    ├── go.mod
    └── pretty.go

If D is under git, then eglot will use D as the project root (eglot uses another package, project, to guess the project root, and project checks whether there is .git (or .hg ...) in directory tree upwards ), and pass D as :rootUri and :rootPath to gopls.

But if D is NOT under git, eglot just uses the current directory ( D/osinf or D/pretty here) as project root and starts two gopls instances respectively when opening osinf.go and pretty.go

So maybe this is the reason why gopls behaves differently?

@stamblerre
Copy link
Contributor

Ah, yes that's probably it. Is there any way for you to manually configure the project root? You'll need to open gopls with the root of your module or a subdirectory (though this is something we're working on improving in the future). This may be something to ask in the eglot issue tracker.

@zbelial
Copy link
Author

zbelial commented Apr 24, 2020

It is Emacs, in which you can do anything you want to do :) So Yes, I've figured out how to configure the project root.
gopls works great for me now, thank you and all guys who hard work for this project.
I'll close this issue now.
Wish you a good day!

@zbelial zbelial closed this as completed Apr 24, 2020
@stamblerre stamblerre modified the milestones: gopls/v0.5.0, gopls/v0.4.1 May 13, 2020
@golang golang locked and limited conversation to collaborators May 13, 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. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
gopls/v0.4.1
Development

No branches or pull requests
3 participants
@stamblerre @zbelial @gopherbot