compiler: resolve importing ambiguity for more complex function calls

Tweak 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 CL 197217.
    
    Fixes golang/go#34503.
    
    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/197122

From-SVN: r276228
This commit is contained in:
Ian Lance Taylor 2019-09-28 00:16:57 +00:00
parent 222e8cb6ca
commit 6e81d34ea2
2 changed files with 6 additions and 1 deletions

View File

@ -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.

View File

@ -12373,7 +12373,12 @@ Call_expression::do_inlining_cost() const
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);
}