[This mail is a heads up about ongoing compiler development; no action required.]
The freeze is going well, and we are looking ahead to getting large changes ready to merge when the window opens at the start of the release, as we do for all large changes. In the compiler, we are working on two different large changes:
- register ABI work to land at the start of Go 1.17 (Feb 1 2021 work begins, Aug 1 2021 release)
- type parameters work to land at the start of Go 1.18 (Aug 1 2021 work begins, Feb 1 2022 release)
We are landing register ABI work in dev.regabi and type parameter work in dev.typeparams. The former is new. Up until now, we were merging master into dev.typeparams. Starting now, we'll merge master into dev.regabi and dev.regabi into dev.typeparams. When Go 1.17 opens, we will merge dev.regabi into master and be back down to just dev.typeparams.
Type parameters will require a lot of new work in the compiler frontend, and we've prototyped some cleanups to cmd/compile that will make that a lot easier and less error-prone. Roughly speaking, the cleanups are (1) replacing Mpint, Mpfloat etc with the go/constant package, (2) replacing cmd/compile/internal/types with types2, and (3) replacing Node with more specific data structures and interfaces. Again, the rationale for these changes is to make the typeparams work easier and less error-prone, and so the changes are limited to that as well.
The cleanups will edit approximately every line of code in cmd/compile/internal/gc. If we landed that work onto dev.typeparams, we'd then have to merge all the dev.regabi work along with all Go 1.17 development into that edited code, which would be rife with error-prone merge conflicts. Instead, we plan to land the cleanups in dev.regabi, so that they will land at the start of Go 1.17. Similarly, wherever we can add new functionality to cmd/compile in support of type parameters that makes sense to land in Go 1.17, we will do it in the dev.regabi branch, to reduce the divergence between Go 1.17 and dev.typeparams and therefore the amount of merging work required over the next 8 months.
We are keeping these branches limited to just the work described above. Please don't send CLs to dev.regabi or dev.typeparams that are unrelated to the register work, the type parameter work, or the (limited scope) cleanup. Such unrelated work should be merged directly to master when the main tree opens.
Again, the point of this mail is just to give a heads up for people who watch Gerrit closely and wonder about the rationale behind the activity on the two branches over the next while. No action is required.