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 The first line of this file holds the git revision number of the last
merge done from the gofrontend repository. merge done from the gofrontend repository.

View File

@ -12373,7 +12373,12 @@ Call_expression::do_inlining_cost() const
void void
Call_expression::do_export(Export_function_body* efb) const 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); this->fn_->export_expression(efb);
if (!simple_call)
efb->write_c_string(")");
this->export_arguments(efb); this->export_arguments(efb);
} }