Bogus error reporting when module is in a subdir of workspace

[pasckosky]

What version of Go, VS Code & VS Code Go extension are you using?

Version Information

• Run go version to get version of Go from the VS Code integrated terminal.

  • go version go1.21.0 linux/amd64

• Run gopls -v version to get version of Gopls from the VS Code integrated terminal.

  • golang.org/x/tools/gopls v0.13.2

• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders.

  • 1.79.2
    695af097c7bd098fbf017ce3ac85e09bbc5dda06
    x64

• Check your installed extensions to get the version of the VS Code Go extension

  • v0.39.1

• Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > Go: Locate Configured Go Tools command.

  • go: /usr/local/bin/go: go version go1.21.0 linux/amd64

  gotests: not installed
  gomodifytags: not installed
  impl: /home/pascky/go/bin/impl (version: v1.1.0 built with go: go1.21.0)
  goplay: not installed
  dlv: /home/pascky/go/bin/dlv (version: v1.21.0 built with go: go1.21.0)
  staticcheck: /home/pascky/go/bin/staticcheck (version: v0.4.6 built with go: go1.21.0)
  gopls: /home/pascky/go/bin/gopls (version: v0.13.2 built with go: go1.21.0)

Share the Go related settings you have added/edited

Run Preferences: Open Settings (JSON) command to open your settings.json file.
Share all the settings with the go. or ["go"] or gopls prefixes.

No modifications

Describe the bug

A clear and concise description of what the bug.
A clear and concise description of what you expected to happen.

Situation:
Directory with

• configs (some yml files)
• python (some tools for internal management)
• resource (some resource files for internal management)
• go (directory with the module and golang code -- go.mod file is in here)
• (entually other modules that are not sharing any file among them)

Problem:
VSCode is not identifying correctly source of packages until I add go directory directly to workspace and work from there
Opening files, I get lots of bogus error reports and complains about not opening from the module root.
Compiler works correctly without any warning or error, proof that errors are mistakenly reported
Code navigation is broken too, Cannot go to, for example, to definition of any symbol

Expected:
since the whole code is in the go directory, all the symbol resultion and debugging should start from the position of the go.mod file.
Having several parallel go directorty must consider each module directory with its own go.mod as separate

Steps to reproduce the behavior:

1. Create a go module or get an existing go module
2. Create new workspace
3. Add go module's parent directory to workspace instead of go module directory
4. See all the bogus error shown in red by clicking any go file

Screenshots or recordings

no screenshot

[findleyr]

@pasckosky gopls should handle the case of a single nested module correctly. Is it possible that you have multiple nested modules?

The solution for this is in progress, which is slated to be done in Q4 of this year. In the meantime, you can use a go.work file to add the modules that you want to work on to your workspace.

[pasckosky]

Thanks @findleyr

I'm trying to produce a clean and simple proof of concept that shows the issue.

If you want to temporarly suspend the issue, I plan to have soon (I cannot forsee how much soon, sadly) the poc to reopen the issue and help for working it out.

[findleyr]

Thanks -- we can leave this open.

[voidfiles]

Not certain if this is the same issue as above, but I was able to create what I feel like is a reproduction.

https://github.com/voidfiles/gorepro

[voidfiles]

So, I checked my go env trying to debug this situation, and I found an errant go.mod in a parent directory, after I removed it my issues went away.

[davidolrik]

I have a similar issue, in a VSCode workspace that used to work.

I have a client directory with multiple projects.
I have one VSCode workspace, with one go project and another non-go folder in the client folder.

client
├── Project.code-workspace
├── go/...
├── go.work
├── go.work.sum
└── non-go/...

In order to make gopls happy I have to create a go.work file in the client folder pointing to my single go project.

The only change to my environment I can think of is me upgrading Visual Studio Code to 1.84.0

[findleyr]

@davidolrik you may be hitting https://go.dev/issue/63917. Do you have a go.mod file in a parent directory of client?

[pasckosky]

Sorry for the delay. lot of stuff.

I was able finally to replicate the issue in a small way

This is the error as shown in code

This is the go run output

and this are the same files, but adding single directories to a code workspace

Structure of the project
`
$ tree
.
├── p1
│   ├── go.mod
│   └── main.go
├── p2
│   ├── go.mod
│   └── main.go
└── p3
└── hello.py

3 directories, 5 files
`

Basically project has several go modules that do not share files.
Here they just import fmt, so it's very basic.
At go run command (and go build) there's no issue at all.
Plugin appears as launching tools from the root of the project instead of the root of the directory and hence giving the bogus error.
When I create a workspace by adding directories, problem does not show.
But this is not a way I can use because I have other files at the root of the project (such as gitignore, docker, readme and other)

Zip of the project is here
poc-code2.zip

Tell me if you need more informations or suggestions.
Anything is appreciated.