In CL 153841, I changed typecheck to rewrite f(g()) calls and return g() statements for multi-valued g() to use temporaries so the backend wouldn't need to worry about tuple-valued expressions anywhere except for in OAS2FUNC statements. In particular, this was motivated to fix memory corruption issues in the old escape analysis code like mentioned in #29197 (comment). (Here is a clearer reformulation of that test case; it used to fail with "GC'd early".)
However, @randall77 asked about suggestions on how to handle a similar issue needed for inserting implicit conversions for GC-shape stenciling in generics, and it made me realize the same issue affects normal OAS2FUNC statements. E.g. this minor variation of the above test case still fails: https://play.golang.org/p/qnq7h6kpSOL
We should probably extend typecheck to check if any of the LHS expressions of an OAS2FUNC are not identical to the respective function call result; and if so, insert autotmps like we already do for f(g()) calls and return g() statements.
Note: even if just one variable/result pair has mismatched types, we should insert autotmps for all of them, to ensure we preserve order-of-evaluation semantics. (Theoretically we could try optimizing this, but I expect it's infrequent enough that we can let SSA handle that instead.)
So next CL can reuse code to rewrite OAS2FUNC.
Passes toolstash -cmp.
Trust: Cuong Manh Le <firstname.lastname@example.org>
Run-TryBot: Cuong Manh Le <email@example.com>
TryBot-Result: Go Bot <firstname.lastname@example.org>
Reviewed-by: Matthew Dempsky <email@example.com>