x/tools/gopls: make go.mod diagnostics on mismatched requirements available when go.work is used

[hyangah]

What version of Go are you using (go version)?

$ go version
go version devel go1.18-577bb7dba1 Mon Oct 11 17:02:03 2021 +0000 darwin/amd64

$ gotip version -m ~/go/bin/gopls
/Users/hakim/go/bin/gopls: devel go1.18-752cc07c77 Mon Oct 4 22:27:40 2021 +0000
        path    golang.org/x/tools/gopls
        mod     golang.org/x/tools/gopls        v0.0.0-20211004195226-db89b5a197b5      h1:WEqrSEDUkBv1VRcnqoCwHjVuLNaomX+FfqtgMh0zXpE=
        dep     github.com/BurntSushi/toml      v0.4.1  h1:GaI7EiDXDRfa8VshkTj7Fym7ha+y8/XxIgD2okUIjLw=
        dep     github.com/google/go-cmp        v0.5.6  h1:BKbKCqvP6I+rmFHt06ZmyQtvB8xAkWdhFyr0ZUNZcxQ=
        dep     github.com/sergi/go-diff        v1.1.0  h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
        dep     golang.org/x/mod        v0.4.2  h1:Gz96sIWK3OalVv/I/qNygP42zyoKp3xptRVCWRFEBvo=
        dep     golang.org/x/sync       v0.0.0-20210220032951-036812b2e83c      h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
        dep     golang.org/x/sys        v0.0.0-20210809222454-d867a43fc93e      h1:WUoyKPm6nCo1BnNUvPGnFG3T5DUVem42yDJZZ4CNxMA=
        dep     golang.org/x/text       v0.3.7  h1:olpwvP2KacW1ZWvsR7uQhoyTYvKAupfQrRGBFM352Gk=
        dep     golang.org/x/tools      v0.1.8-0.20211004222837-36e7bf96e1b8    h1:zFQUKm4Nt1zV3J6uMPl7fxPBrXqPjyP9/ZLjC+3yqvw=
        dep     golang.org/x/xerrors    v0.0.0-20200804184101-5ec99f83aff1      h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
        dep     honnef.co/go/tools      v0.2.0  h1:ws8AfbgTX3oIczLPNPCu5166oBg9ST2vNs0rcht+mDE=
        dep     mvdan.cc/gofumpt        v0.1.1  h1:bi/1aS/5W00E2ny5q65w9SnKpWEF/UIOqDYBILpo9rA=
        dep     mvdan.cc/xurls/v2       v2.3.0  h1:59Olnbt67UKpxF1EwVBopJvkSUBmgtb468E4GVWIZ1I=

What operating system and processor architecture are you using (go env)?

go env Output

$ gotip env

GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/hakim/Library/Caches/go-build" GOENV="/Users/hakim/Library/Application Support/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GOMODCACHE="/Users/hakim/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/hakim/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/Users/hakim/sdk/gotip" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/Users/hakim/sdk/gotip/pkg/tool/darwin_amd64" GOVCS="" GOVERSION="devel go1.18-577bb7dba1 Mon Oct 11 17:02:03 2021 +0000" GCCGO="gccgo" GOAMD64="v1" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/Users/hakim/vultest/tools/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bw/6r6k9d113sv1_vvzk_1kfxbm001py5/T/go-build3919035266=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

--- go.work ---
go 1.18

directory (
        ./a
        ./b
)

--- a/go.mod ---
module a

go 1.17

--- a/main.go ---
package main

import "golang.org/x/tools/go/packages"

var _ packages.Config

--- b/go.mod ---
module b

go 1.17

require golang.org/x/tools v0.1.7

require (
        golang.org/x/mod v0.4.2 // indirect
        golang.org/x/sys v0.0.0-20210809222454-d867a43fc93e // indirect
        golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
)

--- b/b.go --
package b

import (
    _ "golang.org/x/tools/go/packages"
)

Note a/go.mod is missing require.

What did you expect to see?

I hoped to see some sign or hint on incomplete go.mod (maybe suggests running some go commands with -workfile=off?), but currently gopls and go commands are all happy because b is importing golang.org/x/tools/go/packages.

What did you see instead?

Incomplete go.work is not obvious.
Tests & debugs run successfully thank to go.work.

[findleyr]

It looks like there's no easy way to make the Go command give us this information, short of running go list for every module in the workspace. I'd really like to avoid having to do this.

@matloob @bcmills do you think it would be possible to surface this error somewhere from go list when using workspaces?

[bcmills]

do you think it would be possible to surface this error somewhere from go list when using workspaces?

We could in theory have the module loader error out if a package is loaded from some module in the workspace but doesn't require any version of that module, but that could produce false-positives if a package moves into or out of a nested module due to a version upgrade induced by one of the other modules in the workspace.

go work sync does compute this information, but IIRC it also tidies the modules as a side-effect. Still, there may be some command that we could provide to indicate which modules would gain new requirements in a go work sync.