RFR: 8215371: Better nodes for concatenated string literals

[Liam Miller-Cushon]

On Fri, Dec 14, 2018 at 10:47 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> It sounds like you're suggesting a multi-string-concat node, which would
> greedily parse a sequence of strings to be concatenated, and put a list
> of string-valued nodes into it, so that if we had:
>
>      "foo" + "bar " + i + " baz"
>
> we'd have
>
>      StringConcatNode[ Literal["foo"],
>                        Literal["bar "],
>                        Apply(Integer.toString, Var[i]),
>                        Literal(" baz")]
>

Yes, exactly.

The parser would see it as something like `StringConcatNode[
Literal["foo"], Literal["bar "], Ident["i"], Literal[" baz"]]`.


> and then do the folding later?
>

The general constant folding infrastructure already takes care of any
strings that aren't folded eagerly by the parser.
The folding in the parser can be disabled with -XDallowStringFolding, so we
don't rely on it for behaviour.

That seems a more honest solution than trying to balance the tree


Agreed! I wanted to get a sense of whether there was interest in that
approach before before pursuing it.


> (especially as some of the concat nodes might have side-effects,

such as ++x, and we'd have to be careful to manage the order of

side effects.)
>

I think order of side effects would be preserved: the operands need to be
evaluated in pre-order
traversal order, and balancing the string concat nodes wouldn't change
that, right?


> Or, wait for multi-line string literals, and its less of a problem...
>

True, but it'll take some time before it's a ubiquitous solution to this
problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181214/e881cc04/attachment.html>