Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
hyangah opened this issue Oct 12, 2021 · 2 comments
Open

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

hyangah opened this issue Oct 12, 2021 · 2 comments
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
multi-module workspaces
Milestone
gopls/backlog

Comments

@hyangah
Copy link
Contributor

hyangah commented Oct 12, 2021

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.
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Oct 12, 2021
@gopherbot gopherbot added this to the Unreleased milestone Oct 12, 2021
@suzmue suzmue modified the milestones: Unreleased, Backlog Oct 18, 2021
@stamblerre stamblerre added this to To Do in multi-module workspaces via automation Oct 21, 2021
@findleyr findleyr modified the milestones: gopls/on-deck, gopls/v0.8.0 Jan 19, 2022
@findleyr findleyr modified the milestones: gopls/v0.8.0, gopls/v0.8.1 Feb 21, 2022
@findleyr findleyr modified the milestones: gopls/v0.8.1, gopls/v0.8.2 Mar 14, 2022
@findleyr
Copy link
Contributor

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?

@findleyr findleyr modified the milestones: gopls/v0.8.4, gopls/on-deck May 10, 2022
@bcmills
Copy link
Contributor

bcmills commented May 26, 2022

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.

@matloob matloob removed their assignment Sep 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
No open projects
multi-module workspaces
To Do
Milestone
gopls/backlog
Development

No branches or pull requests
7 participants
@hyangah @bcmills @stamblerre @suzmue @gopherbot @matloob @findleyr