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: core functionality does not work in vendor directories #53756

Open
EnigmaCurry opened this issue Jul 8, 2022 · 4 comments
Open
Labels
gopls/workspace gopls NeedsInvestigation Tools
Milestone

Comments

@EnigmaCurry
Copy link

EnigmaCurry commented Jul 8, 2022

What did you do?

I created a simple go program:

package main

import (
	"fmt"
)

func main() {
	fmt.
}

If I put the source code in the path ~/git/vendor/enigmacurry/go-play/hello.go, using gopls to complete on line 8 directly after fmt. it does not yield valid candidates for completion of fmt. Instead, it gives me these completions:

image

However, if I put the same source code in a different directory, ~/git/go-play/hello.go, completion is working correctly:

image

I have created two gopls debug logs:

I have tested in a total of three environments:

  • Emacs 28 lsp-mode (config here)
  • Emacs 28 eglot mode
  • VS Code (vscodium 1.68.1 with golang/vscode-go extension v0.34.1 and default settings)

All environments showed the same result. I have replicated the problem on two separate machines (Arch Linux and Manjaro).

What did you expect to see?

I expected to see valid completions of fmt in both files in both sessions in both directories.

What did you see instead?

The source in ~/git/vendor/enigmacurry/go-play/hello.go does not offer valid completions.

The parent directory ~/git/vendor hosts many other repositories totaling 18GB, which may be a factor as this bug appears to be directory specific.

Build info

gopls is installed directly from the Arch Linux repository:

$ pacman -Qo gopls
/usr/bin/gopls is owned by gopls 0.8.4-1
golang.org/x/tools/gopls v0.8.4
    golang.org/x/tools/gopls@(devel)
    github.com/BurntSushi/toml@v1.0.0 h1:dtDWrepsVPfW9H/4y7dDgFc2MBUSeJhlaDtK13CxFlU=
    github.com/google/go-cmp@v0.5.7 h1:81/ik6ipDQS2aGcBfIN5dHDB36BwrStyeAQquSYCV4o=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/exp/typeparams@v0.0.0-20220218215828-6cf2b201936e h1:qyrTQ++p1afMkO4DPEeLGq/3oTsdlvdH4vqZUBWzUKM=
    golang.org/x/mod@v0.6.0-dev.0.20220419223038-86c51ed26bb4 h1:6zppjxzCulZykYSLyVDYbneBfbaBIQPYMevg0bEwv2s=
    golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
    golang.org/x/sys@v0.0.0-20220209214540-3681064d5158 h1:rm+CHSpPEEW2IsXUib1ThaHIjuBVZjxNgSKmBLFfD4c=
    golang.org/x/text@v0.3.7 h1:olpwvP2KacW1ZWvsR7uQhoyTYvKAupfQrRGBFM352Gk=
    golang.org/x/tools@v0.1.11-0.20220513164230-dfee1649af67 h1:CJwk4qG1fov4WP7/DWhhb7OQVZlQKAl1rEMnDF+ceGU=
    golang.org/x/vuln@v0.0.0-20220503210553-a5481fb0c8be h1:jokAF1mfylAi1iTQx7C44B7vyXUcSEMw8eDv0PzNu8s=
    honnef.co/go/tools@v0.3.0 h1:2LdYUZ7CIxnYgskbUZfY7FPggmqnh6shBqfWa8Tn3XU=
    mvdan.cc/gofumpt@v0.3.0 h1:kTojdZo9AcEYbQYhGuLf/zszYthRdhDNDUi2JKTxas4=
    mvdan.cc/xurls/v2@v2.4.0 h1:tzxjVAj+wSBmDcF6zBB7/myTy3gX9xvi8Tyr28AuQgc=
go: go1.18.2
@gopherbot gopherbot added Tools gopls labels Jul 8, 2022
@gopherbot gopherbot added this to the Unreleased milestone Jul 8, 2022
@EnigmaCurry
Copy link
Author

EnigmaCurry commented Jul 8, 2022

If I rename ~/git/vendor to ~/git/vendor2 it works.

@suzmue suzmue modified the milestones: Unreleased, gopls/later Jul 11, 2022
@ansaba ansaba added gopls/workspace NeedsInvestigation labels Jul 14, 2022
@findleyr findleyr modified the milestones: gopls/later, gopls/v0.9.2 Jul 21, 2022
@findleyr
Copy link
Contributor

findleyr commented Jul 22, 2022

Just looked into this.

I don't think this ever worked. Or at least I reproduced it and tried to bisect all the way back to gopls/v0.7.0 (approximately as far back as one can go without running into build problems), and it seems to have always been a problem.

We should and will still fix, though perhaps with less urgency than if this were a recent regression.

@findleyr findleyr modified the milestones: gopls/v0.9.2, gopls/later Jul 22, 2022
@gopherbot
Copy link

gopherbot commented Jul 22, 2022

Change https://go.dev/cl/419111 mentions this issue: internal/lsp/cache: check for /vendor/ relative to workspace root

@findleyr
Copy link
Contributor

findleyr commented Jul 22, 2022

Have to move on for now, but https://go.dev/cl/419111 contains a sketch of a solution: when checking if a file is "vendored" (generally used to detect that we don't care about it), consider paths relative to workspace root. This makes the included regression test pass, and might be sufficient, but it requires some analysis (and we'll see if other tests pass).

It seems quite possible that this CL is insufficent though. Perhaps we want to consider paths relative to module root, not workspace root.

@findleyr findleyr changed the title x/tools/gopls: completions work in some directories and not in others x/tools/gopls: core functionality does not work in vendor directories Jul 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls/workspace gopls NeedsInvestigation Tools
Projects
None yet
Development

No branches or pull requests

6 participants
@EnigmaCurry @ansaba @suzmue @gopherbot @findleyr and others