Update go1.23

[patrickod]

This PR will be imported into Gerrit with the title and first comment (this text) used to generate the subject and body of the Gerrit change.

Please ensure you adhere to every item in this list.

More info can be found at https://github.com/golang/go/wiki/CommitMessage

• The PR title is formatted as follows: net/http: frob the quux before blarfing
  • The package name goes before the colon
  • The part after the colon uses the verb tense + phrase that completes the blank in, "This change modifies Go to ___"
  • Lowercase verb after the colon
  • No trailing period
  • Keep the title as short as possible. ideally under 76 characters or shorter
• No Markdown
• The first PR comment (this one) is wrapped at 76 characters, unless it's really needed (ASCII art, table, or long link)
• If there is a corresponding issue, add either Fixes #1234 or Updates #1234 (the latter if this is not a complete fix) to this comment
• If referring to a repo other than golang/go you can use the owner/repo#issue_number syntax: Fixes golang/tools#1234
• We do not use Signed-off-by lines in Go. Please don't add them. Our Gerrit server & GitHub bots enforce CLA compliance instead.
• Delete these instructions once you have read and applied them

[bradfitz]

Thanks! I'll review this this evening (outside of GitHub)

[awly]

git diff go1.23.0...origin/update-go1.23 and git diff go1.22.5..origin/tailscale.go1.22 look a bit different, maybe @bradfitz upstreamed some of our internal changes?

[bradfitz]

Per https://github.com/tailscale/go/issues labels, I only upstreamed one of them.

[bradfitz]

Historically we haven't merged one Go release branch into another release branch, but I guess that works. What we did previously was start with a merge commit between our old branch (but not taking any of its contents; just as a git commit parent to keep history) and the Go upstream, and then cherry-pick our handful of changes atop. I think we were doing this because it made git merges for patch releases less painful later? But I forget.

In any case, this style is also fine.

But what are the changes to encoding/gob in two files I see in git diff go/release-branch.go1.23 update-go1.23?

bradfitz@book1pro go % git diff update-go1.23 go/release-branch.go1.23 -- src/encoding/gob
diff --git a/src/encoding/gob/encode.go b/src/encoding/gob/encode.go
index c83071c717..5f4d2539fa 100644
--- a/src/encoding/gob/encode.go
+++ b/src/encoding/gob/encode.go
@@ -601,7 +601,7 @@ func compileEnc(ut *userTypeInfo, building map[*typeInfo]bool) *encEngine {
        if ut.externalEnc == 0 && srt.Kind() == reflect.Struct {
                for fieldNum, wireFieldNum := 0, 0; fieldNum < srt.NumField(); fieldNum++ {
                        f := srt.Field(fieldNum)
-                       if !isSent(srt, &f) {
+                       if !isSent(&f) {
                                continue
                        }
                        op, indir := encOpFor(f.Type, seen, building)
diff --git a/src/encoding/gob/type.go b/src/encoding/gob/type.go
index 13e41728a7..c3ac1dbd61 100644
--- a/src/encoding/gob/type.go
+++ b/src/encoding/gob/type.go
@@ -538,7 +538,7 @@ func newTypeObject(name string, ut *userTypeInfo, rt reflect.Type) (gobType, err
                idToTypeSlice[st.id()] = st
                for i := 0; i < t.NumField(); i++ {
                        f := t.Field(i)
-                       if !isSent(t, &f) {
+                       if !isSent(&f) {
                                continue
                        }
                        typ := userType(f.Type).base
@@ -576,7 +576,7 @@ func isExported(name string) bool {
 // isSent reports whether this struct field is to be transmitted.
 // It will be transmitted only if it is exported and not a chan or func field
 // or pointer to chan or func.
-func isSent(struct_ reflect.Type, field *reflect.StructField) bool {
+func isSent(field *reflect.StructField) bool {
        if !isExported(field.Name) {
                return false
        }

[awly]

Historically we haven't merged one Go release branch into another release branch, but I guess that works. What we did previously was start with a merge commit between our old branch (but not taking any of its contents; just as a git commit parent to keep history) and the Go upstream, and then cherry-pick our handful of changes atop. I think we were doing this because it made git merges for patch releases less painful later? But I forget.

@bradfitz do you want to take a stab and documenting how to do this in https://github.com/tailscale/corp/blob/main/engdoc/updating-toolchain.md? I don't fully understand all the steps you describe.