cmd/compile: support inlining non-escaping closures

[josharian]

Split out from #9337 and #15537.

[rogpeppe]

I'd very much like to see this happen. An idiom that's useful for dealing with lots of returns from a function with long-winded return values is this:

func f() (int, int, error) {
	fail := func(err error) (int, int, error) {
		return 0, 0, err
	}
	if somethingWrong {
		return fail(someError)
	}
	return foo, bar, nil
}

It would be great if this generated exactly the same code as the equivalent:

func f() (int, int, error) {
	if somethingWrong {
		return 0, 0, someError
	}
	return foo, bar, nil
}

[gopherbot]

Change https://golang.org/cl/65071 mentions this issue: cmd/compile: inline closures whenever possible

[huguesb]

Taking a stab at this. I have a CL that can handle the basic test case above, with serious limitations/bugs.

I'm not sure what's going on with captured variables (getting invariant violations in the SSA phase) and would appreciate some guidance from someone more familiar with the compiler.

Also, there doesn't seem to be any easy way to tell if a variable is assigned more than once. Am I missing something?

[gopherbot]

Change https://golang.org/cl/72490 mentions this issue: cmd/compile: inline closures with captures

[gopherbot]

Change https://golang.org/cl/75770 mentions this issue: cmd/compile: fix reassignment check