This patch to the Go frontend by Than McIntosh resolves an importing
ambiguity for more complex function calls. It tweaks the exporter for
inlinable function bodies to work around a problem with importing of
function calls whose function expressions are not simple function
names. In the bug in question, the function body exporter was writing
out a function call of the form
(*(*FuncTyp)(var))(arg)
which produced an export data representation of
*$convert(<type 5>, var)(x)
which is hard to parse unambiguously. Fix: change the export data
emitter to introduce parens around the function expression for more
complex calls.
Testcase for this bug is in https://golang.org/cl/197217.
This fixes http://golang.org/issue/34503.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===================================================================
--- gcc/go/gofrontend/MERGE (revision 276221)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-9112ea664ed9ee5f108158a913812adaf03edf6e
+10a1671d94ddc0c39f2f4b039e5ea33358f414c0
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===================================================================
--- gcc/go/gofrontend/expressions.cc (revision 276221)
+++ gcc/go/gofrontend/expressions.cc (working copy)
@@ -12373,7 +12373,12 @@ Call_expression::do_inlining_cost() cons
void
Call_expression::do_export(Export_function_body* efb) const
{
+ bool simple_call = (this->fn_->func_expression() != NULL);
+ if (!simple_call)
+ efb->write_c_string("(");
this->fn_->export_expression(efb);
+ if (!simple_call)
+ efb->write_c_string(")");
this->export_arguments(efb);
}
