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
Milestone

Comments

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Jan 9, 2020

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
@stamblerre stamblerre modified the milestones: Unreleased, gopls v1.0 Jan 9, 2020
@jayconrod

This comment has been minimized.

Copy link
Contributor

@jayconrod jayconrod commented Jan 9, 2020

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

This comment has been minimized.

Copy link
Contributor Author

@stamblerre stamblerre commented Jan 9, 2020

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

@jayconrod

This comment has been minimized.

Copy link
Contributor

@jayconrod jayconrod commented Jan 9, 2020

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

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jan 9, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.