cmd/compile: rewrite f(g()) for multi-value g() during typecheck
This is a re-attempt at CL 153841, which caused two regressions: 1. crypto/ecdsa failed to build with -gcflags=-l=4. This was because when "t1, t2, ... := g(); f(t1, t2, ...)" was exported, we were losing the first assignment from the call's Ninit field. 2. net/http/pprof failed to run with -gcflags=-N. This is due to a conflict with CL 159717: as of that CL, package-scope initialization statements are executed within the "init.ializer" function, rather than the "init" function, and the generated temp variables need to be moved accordingly too. [Rest of description is as before.] This CL moves order.go's copyRet logic for rewriting f(g()) into t1, t2, ... := g(); f(t1, t2, ...) earlier into typecheck. This allows the rest of the compiler to stop worrying about multi-value functions appearing outside of OAS2FUNC nodes. This changes compiler behavior in a few observable ways: 1. Typechecking error messages for builtin functions now use general case error messages rather than unnecessarily differing ones. 2. Because f(g()) is rewritten before inlining, saved inline bodies now see the rewritten form too. This could be addressed, but doesn't seem worthwhile. 3. Most notably, this simplifies escape analysis and fixes a memory corruption issue in esc.go. See #29197 for details. Fixes #15992. Fixes #29197. Change-Id: I930b10f7e27af68a0944d6c9bfc8707c3fab27a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/166983 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Showing
test/fixedbugs/issue15992.go
0 → 100644
Please register or sign in to comment