From 3309658d3912c1a029ac4126ed64219fbe1a2d1b Mon Sep 17 00:00:00 2001 From: Keith Randall Date: Tue, 18 Mar 2025 14:04:26 -0700 Subject: [PATCH] doc: document change in nil-ptr checking behavior This could bite people during the 1.25 release, so make sure it has good documentation in the release notes. Update #72860 Change-Id: Ie9aaa219025a631e81ebc48461555c5fb898f43f Reviewed-on: https://go-review.googlesource.com/c/go/+/658955 Reviewed-by: Jorropo Reviewed-by: Ian Lance Taylor Reviewed-by: Keith Randall Auto-Submit: Keith Randall LUCI-TryBot-Result: Go LUCI --- doc/next/5-toolchain.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/doc/next/5-toolchain.md b/doc/next/5-toolchain.md index 971fa39608..c4d4744168 100644 --- a/doc/next/5-toolchain.md +++ b/doc/next/5-toolchain.md @@ -9,6 +9,35 @@ information in Go binaries. DWARF 5 generation is gated by the "dwarf5" GOEXPERIMENT; this functionality can be disabled (for now) using GOEXPERIMENT=nodwarf5. + + +The compiler [has been fixed](/cl/657715) +to ensure that nil pointer checks are performed promptly. Programs like the following, +which used to execute successfully, will now panic with a nil-pointer exception: + +``` +package main + +import "os" + +func main() { + f, err := os.Open("nonExistentFile") + name := f.Name() + if err != nil { + return + } + println(name) +} +``` + +This program is incorrect in that it uses the result of `os.Open` before checking +the error. The main result of `os.Open` can be a nil pointer if the error result is non-nil. +But because of [a compiler bug](/issue/72860), this program ran successfully under +Go versions 1.21 through 1.24 (in violation of the Go spec). It will no longer run +successfully in Go 1.25. If this change is affecting your code, the solution is to put +the non-nil error check earlier in your code, preferrably immediately after +the error-generating statement. + ## Assembler {#assembler} ## Linker {#linker} -- 2.51.0