Nested go.mod files not handled well

[raxod502-plaid]

Thank you for the bug report

• I am using the latest version of lsp-mode related packages.
• I checked FAQ and Troubleshooting sections
• You may also try reproduce the issue using clean environment using the following command: M-x lsp-start-plain

Bug description

lsp-mode does not seem to work transparently with nested modules under gopls. When having a nested go.mod file in a subdirectory of a repository, autocompletions and source navigation do not work for the code in the nested project.

Steps to reproduce

Sample code: https://github.com/raxod502-plaid/gopls-issue-repro

Upon opening main.go at the root of the repository, LSP prompts to add the repository root as a workspace directory. This is correct, and required to get autocompletions for that file. Autocompletions work fine for files outside the subproject.

However, upon opening subproject/main.go in the subproject, LSP does not realize that it needs a separate workspace directory, and uses the existing repository root for it. This causes errors to immediately appear (e.g., in lsp-start-plain, errors are highlighted with Flycheck; see screenshots below).

This error appears in *lsp-log*:

2022/04/18 09:59:31 errors loading workspace: You are working in a nested module.
Please open it as a separate workspace folder. Learn more:
https://github.com/golang/tools/blob/master/gopls/doc/workspace.md.
	snapshot=16
	directory=file:///Users/rrosborough/gopls-issue-repro

Screenshots:

Expected behavior

lsp-mode should automatically detect the nested go.mod file and use a separate workspace directory for files under that directory, with no user intervention required.

Or, if this is not possible, instructions on how to manually configure lsp-mode to work correctly for a multi-module project should be available at https://emacs-lsp.github.io/lsp-mode/page/lsp-gopls/.

Which Language Server did you use?

gopls

OS

macOS

Error callstack

No response

Anything else?

See also:

• x/tools/gopls: support multi-module workspaces golang/go#32394
• Gopls: Bad default workspace choice when go code is not at repository root #1978
• multiple gopls instances are started #1275

This is tested using macOS Monterey 12.3.1, Emacs 28.1 configured --with-json --with-native-compilation, gopls e1e2a49 via radian-software/straight.el@e2de88e, and gopls 0.7.5.

[raxod502-plaid]

It looks like with #2619 it might be possible now to simply M-x lsp-workspace-folders-add on the subproject directory, then re-initialize with M-x lsp. Amazing! (Would be great if it were autodetected, though.)

[yyoncho]

It looks like with #2619 it might be possible now to simply M-x lsp-workspace-folders-add on the subproject directory, then re-initialize with M-x lsp. Amazing! (Would be great if it were autodetected, though.)

We cannot solve automatically problems like that because everything is case by case. That is why we leave to the user to interactivelly select the project roots.

[raxod502-plaid]

Would a pull request be accepted to add documentation to https://emacs-lsp.github.io/lsp-mode/page/lsp-gopls/ about how to resolve this error message?

[yyoncho]

Of course.

[raxod502-plaid]

Awesome, will try to submit something later this week.

[raxod502]

Created #3483.