Interesting. I see a segfault with gccgo and with Go versions up through 1.20. From 1.21 onward there is no segfault.

CC @golang/compiler

@khr Appears to be caused by https://go.dev/cl/537775 for #63657.

If no one has done so by tomorrow I'll fix this by making NilCheck return a (ptr, mem) tuple and add it back into the mem chains.
It is a side-effect I don't think we can not put it there.

I think a better fix is just to prevent the nil check from moving blocks during the tighten pass. CL incoming.

@gopherbot please open backport issues.

Backport issue(s) opened: #72862 (for 1.23), #72863 (for 1.24).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

Change https://go.dev/cl/657715 mentions this issue: cmd/compile: don't move nilCheck operations during tighten

We've decided not to backport this change.
We've found instances of code that depend on the buggy behavior. Particularly, code that does:

ptr, err := f()
x := ptr.field
if err != nil { ... return/panic ... }
... use x ...

Where f returns a pointer and an error. f expects its callers to only use the ptr result if the error is nil. And in particular, f returns a nil pointer whenever it returns a non-nil error.

This code is incorrect, in that it dereferences the ptr result before checking the error. The Go spec says that it should nil pointer panic if f returns a nil pointer and non-nil error. But this issue hides the bug in the user's code by pushing the nil check to after the if block. So even though the user's code has a bug in it, that bug does not manifest before the fix to this issue.

Because there is probably code out there dependent on this bug, we're going to just fix this issue going forward (starting in 1.25). We don't want a point release to break anyone's (even incorrect) code without a very compelling reason.

1.25 changelog:

FIXED: the go compiler no longer fixes bugs in your code

😄

Change https://go.dev/cl/658955 mentions this issue: doc: document change in nil-ptr checking behavior

Does it work now, actually? I've tried to build from latest master, ran these snippet:

package main

import (
    "errors"
    "fmt"
)

type A struct{
    B int
}

func ptr[V any](source V, condition bool) (*V, error) {
    if condition {
        return nil, errors.New("test error")
    }

    return &source, nil
}

func main(){
    object, err := ptr(A{B: 42}, true)
    fmt.Println(object.B)
    if err != nil {
        fmt.Println("error case")
    }
}

And it compiles and falls into nil pointer panic on run, despite 3309658 says it should not.
What am I doing wrong?

Go version:

go version devel go1.25-ba50de8429 Thu Mar 20 11:23:35 2025 -0700 linux/amd64

It's the opposite: it says this program should always panic. Before the change, it (or some variant of it) may unexpectedly succeed instead of panicking.

It's the opposite: it says this program should always panic. Before the change, it (or some variant of it) may unexpectedly succeed instead of panicking.

Oh, thank you for clarity. Seems like I misinterpret the document and the issue.
Anyway, if now program always panics here, why not to add that as a compiler error? Marking pointer dereference before nil-check as a compiler error IMO will eliminate roughly 9 of 10 panic problems.

This is radically different than this issue, this issue tl;dr is:

Hello 👋 we found some piece of code where the go compiler does not implement the go spec.

And then fixing the go compiler to implement the go spec properly.

What you are talking about is changing the go spec.

if now program always panics here, why not to add that as a compiler error?

Because a program which always panic is still a valid go program, so the compiler must compile it properly.

Marking pointer dereference before nil-check as a compiler error IMO will eliminate roughly 9 of 10 panic problems.

This is contrary to what the go spec requires, so we can't do that.

If you want to change the go spec I would be having a hard time believing this wouldn't have been proposed before but 2 minutes of searching failed to bring it up.
🤞 look below to see someone awesome linking the proposal to make pointers behave like rust's where *T would always be valid and nil would be Optional<*T> type.

https://github.com/uber-go/nilaway also exists and does pretty much exactly what you say altho warning opinion part incoming:
it is a waste of my time because it had extremely poor Signal-To-Noise ratio and were more focused on adding if v == nil { return someErr } everywhere* rather than fixing real bugs in my codebase.

*which don't actually fix bugs, just turn panics in errors