At this failure rate, this looks like a release-blocker for Go 1.18 via #11811.

(note : I don't know if it's relevant to the current issue, I met this while trying to reproduce the failure in this ticket)

There seems to be an issue with how the test environment is setup/destroyed, which shows up on my machine when running tests with --count=2.

To target a single test, here is the output of what I get when targetting TestPackageCompletion/package_completion_at_valid_position within gopls/internal/regtest/completion :

# running with -count=1 always works :
$ go test -count=1 golang.org/x/tools/gopls/internal/regtest/completion -run TestPackageCompletion/package_completion_at_valid_position
ok  	golang.org/x/tools/gopls/internal/regtest/completion	0.096s

# running with -count=2 always fails :
$ go test -count=2 golang.org/x/tools/gopls/internal/regtest/completion -run TestPackageCompletion/package_completion_at_valid_position
--- FAIL: TestPackageCompletion (0.00s)
    --- FAIL: TestPackageCompletion/package_completion_at_valid_position (0.00s)
        --- FAIL: TestPackageCompletion/package_completion_at_valid_position/singleton (0.00s)
            runner.go:283: mkdir /tmp/gopls-regtest-3631473615/TestPackageCompletion/package_completion_at_valid_position/singleton/gopath: file exists
        --- FAIL: TestPackageCompletion/package_completion_at_valid_position/experimental (0.00s)
            runner.go:283: mkdir /tmp/gopls-regtest-3631473615/TestPackageCompletion/package_completion_at_valid_position/experimental/gopath: file exists
FAIL
closing test runner: errors closing the test runner:
	error(s) cleaning sandbox: cleaning modcache: go command failed (stdout: ) (stderr: ): chdir /tmp/gopls-regtest-3631473615/TestPackageCompletion/package_completion_at_valid_position/singleton/work: no such file or directory; removing files: <nil>
	error(s) cleaning sandbox: cleaning modcache: go command failed (stdout: ) (stderr: ): chdir /tmp/gopls-regtest-3631473615/TestPackageCompletion/package_completion_at_valid_position/experimental/work: no such file or directory; removing files: <nil>
FAIL	golang.org/x/tools/gopls/internal/regtest/completion	0.097s
FAIL

to be clear : I see this running any test in this package (TestSourceFixup, TestUnimportedCompletion ...) with --count=2. I haven't tried tests outside this specific package.

Happens at current master (commit d477ef3e), and at the few commits I tested among the list posted by @bcmills .

I'll address this before beta1.

s/before beta1/soon.

We know why this happens (there are many races during shutdown), but I think it can be avoided.

Change https://golang.org/cl/361655 mentions this issue: internal/memoize: don't pass a context to Acquire

This is going to have to wait until next week. I went down a rabbit hole on gopls shutdown on Friday, and didn't dig my way out in time. I need to focus on the type checker this week.

This issue is currently blocking the first beta release of Go 1.18. Are there any updates?

I had planned to continue work on this today. But with @bcmills agreement I think this should be marked okay-after-beta1. It's not actually a Go issue, and based on @bcmills' thorough investigation I think we know that it's not masking failures right now (the problem being that it would mask failures in the future).

Change https://golang.org/cl/367675 mentions this issue: internal/memoize: do not allow (*Generation).Acquire to fail

Change https://golang.org/cl/367674 mentions this issue: internal/memoize: record the caller of Destroy

I've spotted the Shutdown race and mailed a fix for review.