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: excessive invalidation of analysis results #60918

Closed
adonovan opened this issue Jun 21, 2023 · 1 comment
Closed

x/tools/gopls: excessive invalidation of analysis results #60918

adonovan opened this issue Jun 21, 2023 · 1 comment
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

@adonovan
Copy link
Member

In the course of CL 503195 I noticed that minor changes to source files (such as the insertion of a comment) cause re-typechecking (from syntax) of far more packages than one might expect based on the change. This appeared to be the case both before and after the change in that CL.

For example, if I enable this log line:

func (an *analysisNode) typeCheck(parsed []*source.ParsedGoFile) *analysisPackage {
	if true { // debugging
		log.Println("typeCheck", m.ID)
	}

and run go run ./gopls check ./gopls/main.go, I observe:

  1. first run: typechecks everything.
  2. second run: typechecks nothing.
  3. edit gopls/internal/lsp/cmd/cmd.go: add a comment after the import block. run again: type checks a lot of packages, far more than the upward dependencies of the edit. To pick one at random, honnef.co/go/tools/analysis/facts/purity. Yet go list -deps honnef.co/go/tools/analysis/facts/purity | grep gopls is empty, i.e. we re-typechecked a package that does not transitively depend on the changed package.
@adonovan adonovan self-assigned this Jun 21, 2023
@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 Jun 21, 2023
@gopherbot gopherbot added this to the Unreleased milestone Jun 21, 2023
@adonovan
Copy link
Member Author

D'oh. go run ./gopls after a change to cmd.go produces a new executable with a new hash and a new cache subtree, so of course it does all the work again. Time to find the coffee machine in our new digs...

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

2 participants