Planning Go 1.22

Cherry Mui

unread,

Jul 10, 2023, 6:13:12 PM7/10/23

to golang-dev

Hi gophers,

As described on https://go.dev/s/release, it's time to plan for Go 1.22 development. Tentatively, we expect a soft reopening (for fixes only, not new features yet) next week, and a full general tree reopening shortly thereafter. Please see the tracking issue 60558 for the latest tree status.

Please use this thread to discuss your own plans for the 1.22 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,
Cherry for the Go team

A Guide to Risky Changes.pdf

Meng Zhuo

unread,

Jul 12, 2023, 3:07:41 AM7/12/23

to golang-dev

Hi, I'm plan to finish some features for riscv64:

FP round mode https://go-review.googlesource.com/c/go/+/504737
Vector auxv support https://go-review.googlesource.com/c/sys/+/508676
Vector asm/obj/bytes preliminary support TBD
LR/SC atomic related asm suffix support TBD
plugin support https://go-review.googlesource.com/c/go/+/420114
Some SSA optimazation TBD

WANG Xuerui

unread,

Aug 1, 2023, 5:04:35 AM8/1/23

to golang-dev

For the go1.22 cycle, I plan to try enabling regabi for the loong64 port with the rest of loong64 maintainers, besides finishing any previous work that didn't end up in go1.21. If still more free time is available after that I'll probably look into more loong64 codegen improvements as well.

Heschi Kreinick

unread,

Aug 10, 2023, 1:48:25 PM8/10/23

to golang-dev

Hi Gophers,

The Go team met recently to discuss some notable changes we hope to land in the 1.22 cycle. We talked about risks and downstream work that might be created so that nobody would be surprised. Here’s a brief summary of that discussion. Please keep in mind that these are our best guesses, not commitments. In particular, many features are being implemented in parallel with the proposal process, and might change drastically or even be abandoned altogether if the proposals are declined.

We have a lot of language changes potentially coming up. If you maintain a tool that uses go/types, or otherwise analyzes Go programs, you may have work to do to support 1.22. We suggest you test with tip in a few months, when we hope most changes will have landed in the tree.

Language changes:

Range over int and func:

Implementation should land behind a GOEXPERIMENT soon. (See proposal.) We expect substantial work to be needed in x/tools/go/ssa, and any tool that analyzes data flow.

Type parameters on aliases:

Parameterized aliases would be useful for iterators, but haven’t been formally proposed yet. go/types currently has poor support for aliases, which would need to be fixed before this could land. Those changes would most likely create work for tool authors.

Add builtin zero:

We expect this to land soon. We don’t anticipate much impact on tools.

Less error-prone loop variable scoping:

GOEXPERIMENT=loopvar shipped in Go 1.21 and has been the default within Google for some time. For Go 1.22, we plan to enable the new loop scoping based on the go.mod go line. There may be some tool work needed, including x/tools/go/ssa changes, but it should be small.

Compiler and runtime changes:

Inlining overhaul:

This is likely to land relatively late in the cycle. As the criteria for inlining changes, code that relies on particular functions being inlined may need adjustments.

PGO improvements:

Work will continue throughout the cycle. We expect it to be an uncomplicated win for PGO users.

Execution tracing:

We want to improve the execution trace format to reduce its runtime overhead and make it more useful. The changes will be internal to the runtime and parser package, with no changes to the user experience planned for this cycle.

Other:

Vendoring in workspace mode:

We don’t expect much, if any, impact to tools.

Telemetry:

If time permits, we may experiment with a limited set of basic metrics in the Go command for 1.22.

LUCI migration:

We hope to finish our migration to LUCI during the 1.22 cycle. Only Go contributors will be impacted, and we’re working to make the process as smooth as possible.

Thanks,

Heschi on behalf of the Go team

Ian Lance Taylor

unread,

Aug 10, 2023, 2:25:06 PM8/10/23

to Heschi Kreinick, golang-dev

On Thu, Aug 10, 2023 at 10:48 AM 'Heschi Kreinick' via golang-dev
<golan...@googlegroups.com> wrote:
>
> Type parameters on aliases:
>
> Parameterized aliases would be useful for iterators, but haven’t been formally proposed yet. go/types currently has poor support for aliases, which would need to be fixed before this could land. Those changes would most likely create work for tool authors.

A minor correction: there is an accepted, albeit unimplemented,
proposal for parameterized type aliases: https://go.dev/issue/46477.

Ian

Junxian Zhu

unread,

Aug 11, 2023, 12:55:25 PM8/11/23

to golang-dev

Hi, I'm plan to finish #60072, add ISA levels define for GOMIPS32 and GOMIPS64.

As benchamrk results in #60072, we can get performance improvement in math and crypto operations with newer MIPS processors that support higher ISA levels.

在2023年7月11日星期二 UTC+8 06:13:12<Cherry Mui> 写道：

lab...@linux.vnet.ibm.com

unread,

Sep 11, 2023, 9:03:21 AM9/11/23

to golang-dev

I would like to move forward with https://go-review.googlesource.com/c/go/+/484575. I created this in April and have since gotten no response from the security reviewers. I know this is a questionable area due to the crypto assembler policy but in this case it makes a significant improvement worthy of at least some consideration and a response.

abner chenc

unread,

Nov 14, 2023, 8:15:22 AM11/14/23

to golang-dev

abner chenc

unread,

Nov 14, 2023, 8:15:30 AM11/14/23

to golang-dev

These CLs are for buildmode plugin and shared support on loong64:
https://go-review.googlesource.com/c/go/+/480877
https://go-review.googlesource.com/c/go/+/480875
https://go-review.googlesource.com/c/go/+/480878

I want to support buildmode={shared, plugin} as much as possible in version 1.22. These CLs have been tested and verified locally many times, and their quality is guaranteed.

Reply all

Reply to author

Forward