Skip to content

x/tools/gopls: create a go list GOPACKAGESDRIVER for testing #67615

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.

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

Closed
findleyr opened this issue May 23, 2024 · 4 comments
Closed

x/tools/gopls: create a go list GOPACKAGESDRIVER for testing #67615

findleyr opened this issue May 23, 2024 · 4 comments
Assignees
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@findleyr
Copy link
Member

We lack testing for GOPACKAGESDRIVER in gopls, and while we say it is "unsupported", it technically works, and we have a small yet growing user base on bazel or other alternative build systems.

I think we should clarify our level of support for GOPACKAGESDRIVER, and probably commit to some level of basic support.

As a starting point for investigating driver support and fixing bugs, we need a better way to test. We should write a GOPACKAGESDRIVER that simply delegates to go list behind the driver protocol. Unfortunately, current go list support in go/packages has special handling, and does not align perfectly with the driver protocol, so this is not a small amount of work.

CC @adonovan

@findleyr findleyr added this to the gopls/v0.16.0 milestone May 23, 2024
@findleyr findleyr self-assigned this May 23, 2024
@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 May 23, 2024
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/589135 mentions this issue: go/packages/internal/drivertest: a package for a fake go/packages driver

@adonovan
Copy link
Member

adonovan commented Jun 10, 2024

Gopls invokes go directly from production code, not just tests. For example, these features make use of it:

  • the GCDetails command (code action disabled by default) invokes go build -gcflags=-json=0,file
  • the GoAssembly command (new on Friday) invokes go build -gcflags=-S .
  • the GoTest command (code lens disabled by default) invokes go test.

We haven't really thought about how any these should work with a gopackagesdriver.

The list above is not exhaustive, but many of the other direct calls to go shouldn't arise in a project using an alternative build system:

  • Hover on go.mod invokes go mod why
  • Diagnostics on go.mod invokes go mod tidy
  • the Generate command invokes go generate
  • various other code actions on go.mod files such as go mod {vendor,tidy,upgrade}.

@findleyr
Copy link
Member Author

It seems clear that we should not offer any of those code actions / code lens with a gopackagesdriver.

@adonovan
Copy link
Member

Yeah, it does seem clear. Moved to #67922.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
None yet
Development

No branches or pull requests

3 participants