Planning Go 1.20

[Joedian Reid]

Hi gophers,

Go 1.19 will soon be scheduled for release (🎉!) and the tree will be reopening for 1.20 development. Please see the tracking issue 53812 for the latest tree status. We plan to open the tree to early-in-cycle changes soon after the Go 1.19 GA release which is tentatively planned for August 2nd, 2022. It will be opened up for general changes soon after.

Please use this thread to discuss your own plans for the 1.20 development cycle and to coordinate submission.

(Reminder, this thread is for things you *PLAN TO DO YOURSELF*, not things you want other people to do.)

If you plan on working on potentially risky changes, please follow our attached guide.

If you have insights from past Go development cycles on how this practice can be improved further, we welcome your feedback. The goal is to help everyone ship a robust release and minimize the risk of unexpected delays. Thank you for your help!

Thanks,

Joedian for the Release team

[Meng Zhuo]

I plan to submit plugin support for linux/riscv64 and riscv codegen from upstream.

[Sven Anderson]

I'm still planning to submit the runtime.Pinner API in this CL. However, first I would need some guidance from the runtime team (Austin Clements et.al.) in which direction the implementation should go before I can continue. (See last comment in the issue.)

Thanks,

Sven

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/b7e144d1-9614-45e1-9d9d-1832a8d48605n%40googlegroups.com.

[lab...@linux.vnet.ibm.com]

We have been told there will be a P10 ppc64le builder at OSU within the next month. Once we can get P10 builders up and running, our plans are to submit changes to add support for P10 to our assembler and compiler and leverage those instructions where beneficial.

In addition to that work, we have some miscellaneous changes to submit for some clean up and minor performance improvements.

[guangyuan zhou]

I hope tthe CLs in cmd/compile, cmd/link: generate dwarf type info in compiler can be merged into Go 1.20, I will resolve the review comments soon.

[Austin Clements]

Here are the runtime/compiler team's plans for 1.20:

- Core project health: We're going to spend a lot of our effort "cleaning house" and working on infrastructure improvements. A lot of this is completely internal (e.g., improving the Go release process), while other parts should improve the experience for all Go contributors. Some of this has already happened: people may have noticed a flurry of CLs a couple weeks ago that were part of an internal "friction fixit" week we did.

- Continued improvements to generics. We're still pinning down exact priorities here.

- Unified IR: Finish loose ends and enable by default. Both the old and new IR paths will remain for a release and then we'll remove the old IR paths.

- PGO preview: We're planning to release an initial preview of profile-guided optimization support. Expect a public proposal and design doc soon. The initial version will be focused on a few optimizations that clearly benefit from PGO and on how to integrate PGO into the Go build ecosystem.

- cmd/cover redesign (Proposal, CLs): This is an almost complete rewrite of Go's coverage tooling. This should fix many long-standing issues with the existing tooling and extend coverage outside unit tests to whole applications. For example, we're planning to use this to track coverage of the Go toolchain itself. :)

And of course many smaller things. A couple notable changes we plan to land soon to maximize their soak time are 1-bit heap bitmaps and GC pacer tweaks.

I see the other exciting improvements to the runtime and compiler people are planning in this thread. We're tracking those, too. :)