Thank you for the report.

CC @adonovan, as this coincidentally seems very similar to https://go.dev/cl/443636: clearly a package path and import path are being confused here (though I don't necessarily think this will be fixed by that CL -- goimports is mostly disconnected from the rest of gopls).

@inliquid are you by any chance working on an open-source project? If not, we can try to reproduce from scratch.

@findleyr, unfortunately this is a private repo.

I also found that when you use "References" or "Implementations" features, VS Code also displays paths from vendor:

Working on a private repo I've noticed the same.

Change https://go.dev/cl/448377 mentions this issue: gopls/internal/lsp/cache: use Package.FileSet where possible

Hi @inliquid, I've tried to reproduce this bug a number of ways but with no success. (For example, I vendored a number of packages, created a file with missing imports of packages among the vendored set, and ran 'gopls imports' on them, and each time it got the right answer. I tried various versions of gopls before recent changes in relevant logic. And I tried it without and without a go.work file. I also looked at the various places in our code that we've flagged as suspicious in the way in which they convert between import paths and package paths, and none of them looks like an obvious candidate to explain it.)

I understand this is private code you can't share, but next time you encounter the problem, would you be willing to spend a few minutes trying to create a reproducible test case in terms of packages you can share? As soon as I can reproduce this I can work on a fix. Thanks.

@adonovan I work with gopls@master and update it regularly, does it say anything?

Just tried once again by adding glob.Glob in one of working files and pressing Ctrl-S:

If you have any idea what additional information I can provide please let me know. You are correct this is private repo so I can't share its code unfortunately.

Still no luck reproducing this.

The "implementations" issue you mention in #56291 (comment) is likely a dup of #56169, which should now be fixed.

Well the problem is definitely still present. Except for sharing the project files, what else can I do to help in solving it?

I, and several of my coworkers, are also experiencing this issue. I hacked together a shell script that seems to reliably reproduce it (tested in git-bash and cygwin).

Requires gopls to be installed as a command (I ran go install golang.org/x/tools/gopls@latest).

#!/bin/sh

# create a new dir to hold our package
mkdir vendorbug
cd vendorbug

# create a simple main.go that uses github.com/google/uuid
cat > main.go <<EOT
package main

import (
	"fmt"

	"github.com/google/uuid"
)

func main() {
	fmt.Printf("This is a test package.")

	myUUID, _ := uuid.NewRandom()
	fmt.Printf("The UUID generated was: %s", myUUID)
}
EOT

# create a module
go mod init github.com/bferullo/vendorbug
go mod tidy
go mod vendor

# remove github.com/google/uuid import from main.go
sed --in-place -E '/github.com\/google\/uuid/d' ./main.go

# (verify here that main.go no longer has that import, if you want)

# run gopls imports
gopls imports -d main.go

# EXPECTED RESULT: "github.com/google/uuid" reappears in import block
# OBSERVED RESULT: "github.com/bferullo/vendorbug/vendor/github.com/google/uuid" appears in import block

Huh, FWIW that script didn't reproduce the bug for me. I completely believe this bug exists, but it must depend on state (likely the state of the module cache).

Same here. github.com/google/uuid appears each time. I tried with GOMODCACHE=$(mktemp -d) too. Could you @bferullo try with that env var and report whether it still happens?

Same here. github.com/google/uuid appears each time. I tried with GOMODCACHE=$(mktemp -d) too. Could you @bferullo try with that env var and report whether it still happens?

It does still repro. I also imagine the issue has to do with some persistent state, but I can't figure it out either -- I even installed go, gopls, and gitbash on a machine that previously had none of those, and was able to repro it there as well.

can you give the exact versions of go and gopls you used?

I also can reproduce the issue with the above script. Since I also run it on Windows, can OS be a problem?

Anecdotally, some colleagues who run OSX also encounter this issue. I'll see if I can get them to test the script specifically.

Still no luck reproducing this on macOS using go1.19 (or go1.19.5) and the script and environment above, and either gopls@v0.11.0 or today's gopls@latest.

I still can reproduce this with the script from above comments on a brand new Windows 11 machine (old one was Windows 10):

 import (
        "fmt"

+       "github.com/bferullo/vendorbug/vendor/github.com/google/uuid"
 )

PS: I'm using gopls@master with latest commits.

Change https://go.dev/cl/498695 mentions this issue: gopls/internal/regtest: add a test for goimports and windows vendoring

The test in the above CL (based on the script provided by @bferullo reproduces the failure on our windows trybot. I'll fix this for gopls@v0.12.1 (which we expect not long after v0.12.0...)