Planning Go 1.18

[Carlos Amedee]

Hi gophers,

Go 1.17 is scheduled for release (🎉!) and the tree is in the process of reopening for 1.18 development. Please see the tracking issue 47351 for the latest tree status, but as of this moment it's accepting early-in-cycle changes only. It will be opened up for general changes soon after that.

Please use this thread to discuss your own plans for the 1.18 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.)

Please take special care when working on risky changes. As a reminder:

A change is risky if it can cause failures that are hard to diagnose (for example, changes to the runtime, GC, compiler, linker, TLS, other low-level component, or complex changes that need soak time under production workloads), or if it requires many CLs that are hard to revert (for example, large CLs or stacks of CLs).

If you’re planning on working on a change that may be risky, please do the following:

1. Unless the entire change is absolutely trivial to revert, protect the new code paths with a boolean flag, prefixed with "go118", that can be used to quickly toggle back to the old implementation. It can be a simple bool constant, for example, const go118UseEvenBetterLinker = true. Such flags must be findable by a simple grep for the string "go118". That way we can find them without missing any, and they can be cleaned up when we get to the Go 1.19 cycle.

2. Consider how you would answer the following questions for your change:

How risky is the change you're planning to make?

How will you know if it is working as intended?

How much production testing does it need for you to be confident it is working as intended?

At what time should the keep/revert decision be made?

3. Create a tracking issue in the Go 1.18 milestone with a release-blocker label. This issue will be used to track progress on the feature and make the final decision for Go 1.18.

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

Thanks,

Carlos for the Release team

[Eric Fang]

I'll file the arm64 new assembler refactoring patch, it is a relatively large patch and may take some time to review and discuss the plan. I would be grateful if the maintainers of the relevant modules consider setting aside some time for this.

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

I plan to submit patches to enable the new register ABI for PPC64.

I have an assembler implementation for crypto AES-CBC that improves performance by 2X on ppc64le.

[Kevin Burke]

I would still like to find a more intuitive solution to the problem of finding out where Go is going to install binaries on a given user's machine. There is some discussion here but the winning suggestion so far - "go list -f {{.Target}} $IMPORTPATH" - is far from intuitive. https://github.com/golang/go/issues/45546

The context is that I'm helping folks at my company like the designer get Go software installed and running on their machine and every time I need to take a moment to figure out where Go is installing binaries and then get them to add $HOME/go/bin to their $PATH. 

Basically what I want is like "go env GOBIN" or something with similarly simple semantics to print out $HOME/go/bin or whatever other directory is configured. I can then reference that in scripts to start the server - "exec $(go env GOBIN)/meter-server" or whatever, without needing to muck with the PATH at all.

[Meng Zhuo]

I'll try to add regabi support for riscv64 and some runtime performance improvement.