Currently, when a user opens a workspace with no top-level module but
multiple modules in subdirectories, gopls treats that as an invalid
build configuration and reports an error message that may be difficult
for the user to understand (a go list error message about creating a
main module in the top-level directory). Instead, show a more useful
error message about the gopls workspace layout in both the progress bar
and as a diagnostic on every open file.

This fix only works for GO111MODULE=on (for now) because it's a lot
easier to interpret user intent, and the go command will return no
packages. The next step will be to improve error messaging for
GO111MODULE=auto and for users with nested modules.

Updates golang/go#42109

Change-Id: I702ca6745f7e080ff6704ade7843972ab469ccf3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272346
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>

When GO111MODULE=auto and the workspace is outside of $GOPATH/src, we
should still show diagnostics about how to correctly configure
multi-module workspaces. We should not show these warnings for
workspaces outside of a module within GOPATH.

This adds an extra piece to the WorkspacePackages error logic--we may
still need to show the errors even if WorkspacePackages returned
results. We should eventually consolidate all of this logic to be more
cohesive, but for now I think it's more important to cover all of the
different cases and add tests.

Updates golang/go#42109

Change-Id: I673a03c9840cdaaf7f058de1cda3bf36b96fa7d3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275553
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>

Currently, when a user opens a workspace with no top-level module but
multiple modules in subdirectories, gopls treats that as an invalid
build configuration and reports an error message that may be difficult
for the user to understand (a go list error message about creating a
main module in the top-level directory). Instead, show a more useful
error message about the gopls workspace layout in both the progress bar
and as a diagnostic on every open file.

This fix only works for GO111MODULE=on (for now) because it's a lot
easier to interpret user intent, and the go command will return no
packages. The next step will be to improve error messaging for
GO111MODULE=auto and for users with nested modules.

Updates golang/go#42109

Change-Id: I702ca6745f7e080ff6704ade7843972ab469ccf3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272346
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>

When GO111MODULE=auto and the workspace is outside of $GOPATH/src, we
should still show diagnostics about how to correctly configure
multi-module workspaces. We should not show these warnings for
workspaces outside of a module within GOPATH.

This adds an extra piece to the WorkspacePackages error logic--we may
still need to show the errors even if WorkspacePackages returned
results. We should eventually consolidate all of this logic to be more
cohesive, but for now I think it's more important to cover all of the
different cases and add tests.

Updates golang/go#42109

Change-Id: I673a03c9840cdaaf7f058de1cda3bf36b96fa7d3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275553
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>

This change adds a diagnostic and error message that appears when a user
edits a nested module in legacy mode. At first, I thought a diagnostic
would be enough, but it's actually quite difficult to spot it when you
have a bunch of "undeclared name" diagnostics caused by the nested
module, so I figured a progress bar error message would also be useful.

This error message just indicates to the user that they should open the
nested module as its own workspace folder.

Also, while debugging this, I noticed that command-line-arguments
packages can have test variants, which we were never handling.
So I addressed that in this change.

Fixes golang/go#42109

Change-Id: Ifa6f6af401a3725835c09b76e35f889ec5cb8901
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275554
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>