-
Notifications
You must be signed in to change notification settings - Fork 18k
update release-branch.go1.18 with changes for Go 1.18 final (Go 1.18.1 and future minor releases are out of scope) #51460
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
CL 389474 to fix #51250 |
Thanks, added it to the list. |
By now, CL 389554 landed, so release-branch.go1.18 has all "for 1.18" CLs that landed while the tree was still frozen for 1.18 development. Next up are the fixes since then. I reviewed all open release-blocking issues in Go 1.18 milestone, as well as open CLs targeting the Go 1.18 release branch and made sure everything in those 2 lists is included above. Then confirmed their order. Based on that, preparing the following stack that will check off all the boxes present at the time of this comment:
Mailed out the stack (10 commits) with https://go.dev/cl/389914 at the top. 6 of 10 cherry-pick CLs need a Code-Review vote. |
CL 390020 should be backported to the 1.18 branch for #51479. I can do the backport if you like. |
Thanks Ian. It is probably better if I add it to the top of the existing stack for better visibility, and it's very easy for me to do since there aren't any conflicts. It's sent as CL 390022. Also added it to the list in the original issue. |
CL 388354 has just landed and should be backported, thanks! |
Thanks! Added and mailed https://go.dev/cl/390095. |
CL 390025 needs to be backported once it has landed. [edit] This has landed. |
CL 390314 needs to be backported once it has landed. [edit] This has landed. |
CL 390214 has landed and should be backported, thanks! |
https://go.dev/cl/390914 should be cherry-picked too. EDIT: added a check-box |
https://go.dev/cl/388194, although if it doesn't make the boat it can probably wait for 1.18.1. |
CL 391135 needs to be cherry-picked once it has landed. [edit: this has now landed] |
CL 391154 should also be cherry-picked once it has landed. [edit: This has now landed.] |
CL 391275 needs to be cherry-picked once it has landed. [edit: This has now landed.] |
CL 391994 needs to be cherry-picked. Background: for generic code, the compiler was using the wrong dict param for getting the dictionary type, causing mis-compile code when disable inlining. Debuggers (like devel) will have issues debugging generic code. |
Thanks @cuonglm. At this point we are very close to the release and so the bar for fixes is very high. Per go.dev/s/release, "We may prefer to issue a release with a known but very rare crash than to issue a release with a new but not production-tested fix." I will make a backport for CL 391994, make sure it passes tests, and then generate a CL for resolving #51532, at which point we will need to aim to stop changing release-branch.go1.18 for anything but the most critical issues that must block the final release. For everything else, we'll need to consider backports to minor releases, or waiting for Go 1.19. Thanks. |
@dmitshur Thanks for clarifying, I made https://go-review.googlesource.com/c/go/+/392614 for backport CL 391994. IMHO, that's a critical issue, which make compiler generate invalid code and can cause runtime crashes/wrong behavior. We were able to catch that bug with inlining disable does not mean we have enough coverage test case for making sure the bug won't happen with inlining enable. How do you think @randall77 @mdempsky ? |
I think waiting is ok. I agree that #51413 isn't necessarily just a problem when turning inlining off. It could come up in other scenarios. That said, the code in question has been checked in since ~July, so the fact that we only found it recently means it is probably pretty rare. We can wait 2-3 weeks for a fix. |
@cuonglm @randall77 Thanks. CL 392674 is the last CL needed resolve a release-blocking issue in 1.18 milestone, so after it's in, I will tentatively close this issue. |
Ok, as of this writing we are down to just 3 release-blocking issues in the Go1.18 milestone:
I'll mark this closed since the |
The release-branch.go1.18 branch as of this moment points to commit cb5a598, from when the Go 1.18 RC 1 release was made. Before the final Go 1.18 release, the branch needs to be updated to include all changes that are meant for Go 1.18, both those that landed while the tree was frozen, and a number of additional fixes that landed after the tree reopened for 1.19.
This is the tracking umbrella issue to collect the remaining CLs that need to land on the release branch, and sort them all. CLs that need to submitted first are on top of the list:
⤷ crypto/x509: intermittent failures on darwin/amd64 with ‘x509: “…” certificate is expired’ since 2021-11-06 #51209
⤷ cmd/go/internal/modfetch: erroneously resolves a
v2.…+incompatible
version when av2/go.mod
file exists #51324⤷ everything else up to "internal/goversion: update Version to 1.19"
⤷ runtime: in generic code, convert iface to type failed with "types from different scopes" #51250
⤷ cmd/go:
go run golang.org/x/example@<version>
panics when run in a workspace #51390⤷ go/types, types2: scope for
:=
-defined range iteration variables is incorrect #51437⤷ runtime: finalizer call has wrong frame size #51457
⤷ cmd/go:
go work init .
adds./.
instead of.
#51448⤷ cmd/go:
go work init .
adds./.
instead of.
#51448⤷ cmd/go: workspace documentation is uninformative #51301
⤷ syscall: TestRlimit fails on arm7hl Linux in 1.18rc1 #51479
⤷ testing: fuzzing with float64 can produce errors and unparsable corpus files #51258
⤷ testing: fuzzing with float64 can produce errors and unparsable corpus files #51258
⤷ cmd/compile: embedding comparable is not considered in calculating type sets #51472
⤷ go/types, types2: nil underlying for selectors on the current type decl #51509
⤷ go/types, types2: duplicate type instances are not recorded in Info.Instances #51494
⤷ go/types, types2: document predicates on generic types #50887
⤷ go/types, types2: disable inference for instances of defined types (not functions) for 1.18 #51527
go.mod" if language version < 1.18
⤷ cmd/compile: missing hint to check go.mod if language version < 1.18 and declare a generic type or func #51531
⤷ internal/fuzz: int32 corpus values that aren't valid UTF-8 runes marshal as 0xFFFD #51528
⤷ cmd/gofmt: gofmt introduces a trailing comma in some type parameter lists where not needed #51548
⤷ cmd/go: git revision information stamping on CentOS 7 fails with Go 1.18rc1: error obtaining VCS status: exit status 128 #51253
⤷ go/types, types2: disable field accesses through type parameters for now #51576
⤷ go/types, types2: be consistent about the words 'parameterized' vs 'generic' in error messages and documentation #49593
⤷ cmd/compile: able to use interface with type constraints #51578
⤷ cmd/compile: miscompilation of comparison between type parameter and interface #51522
⤷ cmd/compile: miscompilation of comparison between type parameter and interface #51522
⤷ go/types, types2: type inference should unify interface types #51593
⤷ testing: minimized crasher is unrelated to original #48326
⤷ testing: minimized crasher is unrelated to original #48326
⤷ cmd/compile: internal compiler error: weird package in name: p.a => a from "test/p", not "" #51423
https://go.dev/cl/392614: [release-branch.go1.18] cmd/compile: fix wrong dict param when getting dict type⤷ cmd/compile: irgen uses wrong dict param to generate code for getting dict type #51413 (to be considered for Go 1.18.1)
⤷ x/website: update to latest spec just before release #51532
(The boxes can be checked after the corresponding CLs are submitted to release-branch.go1.18.)
CC @golang/release, @randall77, @griesemer.
The text was updated successfully, but these errors were encountered: