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.

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

x/tools/gopls: don't treat test mains as workspace packages #36473

Closed
stamblerre opened this issue Jan 9, 2020 · 4 comments
Closed

x/tools/gopls: don't treat test mains as workspace packages #36473

stamblerre opened this issue Jan 9, 2020 · 4 comments
Labels
FrozenDueToAge 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

@stamblerre
Copy link
Contributor

The initial workspace load currently runs a go list ./... query for the entire workspace, so we get all packages in the workspace, including test mains. We need to stop providing diagnostics for these packages, as they aren't useful.

@jayconrod, @matloob: Is there any reliable way to detect that a package is a test main?

@gopherbot gopherbot added this to the Unreleased milestone Jan 9, 2020
@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 Jan 9, 2020
@stamblerre stamblerre modified the milestones: Unreleased, gopls v1.0 Jan 9, 2020
@jayconrod
Copy link
Contributor

Generated test main packages have import paths that end with .test. Their package names are main. They should have one entry in GoFiles, which is inside the build cache.

{
	"Dir": "/Users/jayconrod/Code/test",
	"ImportPath": "m.test",
	"Name": "main",
	"Root": "/Users/jayconrod/Code/test",
	"Stale": true,
	"StaleReason": "stale dependency: m",
	"GoFiles": [
		"/Users/jayconrod/Library/Caches/go-build/4e/4ed90dfb73b1b23fb2030ce6dc74671fc821753d1018c3a52b818077266d5810-d"
	],
...
}

@stamblerre
Copy link
Contributor Author

Is checking for those 3 things sufficient, or should we also check that the dependencies are exactly os, testing, and testing/internal/testenv?

@jayconrod
Copy link
Contributor

Testing those 3 things should be sufficient. Even just the first two would be fine unless someone deliberately names their package something.test.

The list of imports is not stable. testing/internal/testenv could change. Also the -coverpkg flag will cause the test main to import every instrumented package, whether it's being tested or not.

@gopherbot
Copy link

Change https://golang.org/cl/213660 mentions this issue: internal/lsp: store workspace package IDs with package paths

@stamblerre stamblerre modified the milestones: gopls/v1.0.0, gopls/v0.4.0 Jul 22, 2020
@golang golang locked and limited conversation to collaborators Jul 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge 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