RFR: 8215371: Better nodes for concatenated string literals

[Alex Buckley]

On 12/14/2018 1:24 PM, John Rose wrote:
> Slightly more principled solution (along one axis):  Treat string concat
> as a similar form to existing signature-polymorphic methods invokeExact,
> etc.  That treats it as a method call (rather than special control flow or
> block structure), so common method-call code would apply.
>
> Then at code generation time transform the sig-poly call down to indy
> or open-coded StringBuilder stuff or whatever else the user has requested.
>
> The advantage of sig-poly calls is that they don't try to dictate argument
> types; they accept actual arguments as-is.  This is what you want to
> preserve if you are going to try to hold a high-level form of AST and
> defer lowering to indy or SBs to a later phase.

FYI John is referring to the treatment of sig-poly methods here:

https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.12.3-400

(Contrast "The compile-time parameter types are the types of the formal 
parameters of the compile-time declaration." with "The compile-time 
parameter types are the types of the actual argument expressions."  The 
compile-time parameter types, amongst other things, flow into the 
symbolic reference to a method that must be put in the class file, per 
13.1.)

Alex