Further simplified:

package x

type Node struct {
	Orig *Node
}

var sink *Node

func f() {
	var n Node
	n.Orig = &n

	m := n
	sink = &m
}

And here's a loop involving multiple nodes:

package x

type Node struct {
	Orig *Node
}

var sink *Node

func f() {
	var n0, n1 Node
	n0.Orig = &n1
	n1 = n0

	m := n1
	sink = &m
}

Interestingly, esc.go -m=2 doesn't seem to have printed an explanation for either of these cases, because they're "moved to heap" escapes rather than "escapes to heap".

Go 1.13 didn't print anything useful about why these variables were heap allocated, so I don't think it's release critical that Go 1.14 print anything useful for them either. But it is release critical to not infinite loop compiling with -m=2.

Properly handling loops like this will require a bit more restructuring to the walk code, which I don't feel comfortable doing this late in the release. I'm inclined to simply detect that we've hit a loop, print a warning that the path is incomplete, and return. We can figure out how to better diagnose these rho-shaped loops in Go 1.15.

Change https://golang.org/cl/206619 mentions this issue: cmd/compile: fix -m=2 infinite loop in escape.go

And finally, here's an example where the original node isn't part of the assignment cycle:

package x

type Node struct {
	Orig *Node
}

var sink *Node

func f() {
	var n1, n2 Node
	n1.Orig = &n1
	n1.Orig = &n2

	sink = n1.Orig.Orig
}

Context: I was wondering if CL 206619 was overkill, and I could just check if we loop back to src again rather than keeping track of every visited location. This example shows checking for src alone is insufficient to detect cycles.

Change https://golang.org/cl/206820 mentions this issue: test: add another test case for #35518

Since CL 206619 is submitted, this isn't a release blocker for Go 1.14 anymore.

The underlying issue that there can be cycles in the escape path and we should ideally explain that properly is still a concern though.