Please review http://cr.openjdk.java.net/~aw/8134941/ for
https://bugs.openjdk.java.net/browse/JDK-8134941 .
This change adds support for ES6 template literals (both untagged and
tagged). This is rather heavy patch, so let me walk you through it.
Instead of using the existing EditStringLexer, I took a somewhat
different approach. I've added 4 lexer tokens for the different template
string portions cf. 11.8.6 and let the parser decide what to do with it.
These are then treated different depending on whether the literal is tagged:
* untagged: desugared to a string concatenation using +
* tagged: desugared to function call (cf. 12.2.9.2) tag(
RuntimeCall(GET_TEMPLATE_OBJECT, [...rawStrings], [...cookedStrings]),
...evaluatedExpressions ), where rawStrings and cookedStrings are the
unescaped and escaped string portions, respectively. CR and CRLF in the
strings are always converted to LF.
The EditStringLexer did not correctly count quoted braces in embedded
expressions (e.g., `${ "}" }` would error), so I've hooked an open brace
counter into Lexer#lexify() directly that is context-aware. It's purpose
is to break out of the nested Lexer at the closing RBRACE, and then
continue with scanning the rest of the literal.
Template literals are always scanned as a whole, quote-to-quote (as with
EditStringLexer). This turned out to be a problem with embedded
functions in expressions and lazy/optimistic compilation on:
Parser#skipFunctionBody would skip over the body and restart lexing at
the RBRACE, forgetting about the embedding string context. I've worked
around this in skipFunctionBody by skipping over to the RBRACE directly
if it is already in the token stream (which it is because we've already
scanned to the end quote).
Template strings use the same quotes (`) as exec strings in -scripting
mode; if mixed, --language=es6 takes precedence over -scripting,
ES5+scripting is unaffected.
Outstanding correctness issues not dealt with:
* 12.2.9.3 GetTemplateObject stipulates that the returned template
object be cached and unique. I don't know why you'd want the spec to
demand caching rather than allow it (functionally it does not make a
difference, but you could observe it not being cached in a test).
* 12.2.9.5 Evaluation: string concatenation using + is slightly
off-spec. There are two way to solve this: (a) wrap the expressions in a
ToString UnaryExpression (or RuntimeCall) or (b) generate a call to
concat with interleaved string and expression arguments.
Testing: ant -f make/build.xml test-pessimistic test-optimistic
Thanks,
Andreas
