cc @bradfitz

If this feature is not ready for non-experimental use one option would be to still require GOEXPERIMENT=gocacheprog but move it from toolchain build time to toolchain invocation time.

/cc @bcmills for thoughts

Per the discussion in https://go.dev/cl/c/go/+/486715/14#message-086f5f820978ba6f6b2afc0589b397894afddf93, I think GOCACHEPROG needs proper integration tests in the main Go repo before we can consider promoting it to non-experimental status.

Change https://go.dev/cl/556997 mentions this issue: cmd/go: add initial cacheprog integration tests

it also needs docs, and preferably importable type definition

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Placed on hold.
— rsc for the proposal review group

An item from https://go.dev/cl/556997:

The cacheprog bits use "object" when other parts of the cache use "output." For example in prog.go:

vs the OutputID type and its use elsewhere:

It would be good to get the cacheprog path using "output" instead of "object."

Another issue uncovered in testing: it appears that with GOCACHEPROG enabled we still end up using GOCACHE for fuzzing data. We should at least consider how we might address that, in case it affects the final GOCACHEPROG API.

(https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/cache/prog.go;l=46-47;drc=5e3c4016a436c357a57a6f7870913c6911c6904e)

It seems like maybe fuzzing's use of GOCACHE for something completely different was a mistake. Perhaps that should be rethought.

Moving back to active now that there are pending tests.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

It seems like maybe fuzzing's use of GOCACHE for something completely different was a mistake. Perhaps that should be rethought.

There is #48901 that proposed a new environment variable.