Seeing this too. Does opting into the experiment need rebuilding parts of the stdlib, such as fmt?

(attn @findleyr @golang/release)

This is probably due to recompilation of std archives (which are cached following https://go.dev/cl/460635).

Perhaps we should add a special case and build archives with GOEXPERIMENT=loopvar here:
(https://cs.opensource.google/go/x/playground/+/master:Dockerfile;l=90;drc=6821b5629810defb1ea68149e090b5b86576d7ca)

@bcmills can you confirm whether adding a second build of std would suffice? (I'm not familiar with GOEXPERIMENT handling in the Go command).

CC @rsc, who added support for GOEXPERIMENT in https://go.dev/cl/511640.

can you confirm whether adding a second build of std would suffice? (I'm not familiar with GOEXPERIMENT handling in the Go command).

Yes, adding GOCACHE=/gocache GOEXPERIMENT=loopvar ./bin/go install --tags=faketime std should suffice.

That said, I question whether the benefit of doing so would be worth the cost, given the need to deploy and maintain it. I hope that the revised loop variable semantics will soon be available without setting GOEXPERIMENT at all. 🙃

I hope that the revised loop variable semantics will soon be available without setting GOEXPERIMENT at all. 🙃

It is already available if you select "Go dev branch" on the playground (since fe1daf2)

@fzipp that's a great point. In that case, I don't think we should bother making this work better for 1.21. It would increase the disk space required for every build, and as @bcmills noted would require maintenance.

With 1.22 out, this seems to be even worse with GOEXPERIMENT=rangefunc. I'm getting timeouts 100% of the time now with this code.