Hannes, Attila,
thanks for your reviews and sorry for the late reply.
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).
It took me some time to figure this out. Maybe some more explanatory
comments would be good. Does this also apply in other cases?
From the top of my head I'd say no, because we don't start the lexer at
arbitrary positions, but only at a brace, and no other case comes to
mind where we could end up with different tokens here. Yes, some more
comments wouldn't have hurt. :)
It would probably be good to use the same code for scripting-mode `exec
strings` which still have this and the quoting issue I mentioned.
We can probably file the issues as separate bugs and fix them later.
One thing I want to do is add some more tests. Although your test
script covers a lot of stuff (for its size) I would like to add a bit
to it.
Please do!
Regarding caching of template objects: yes, we should follow the spec
here, I deliberately left that out because I wanted to focus on the
parser changes.
I’m sometimes in two minds about RuntimeNode (especially the fact that it
currently can’t receive primitive parameters), but I have to admit that in this
particular case it made the integration of the feature into the runtime fairly
easy; it was really the parser parts that were tricky.
Yes, I like how simple it was to add runtime support with this approach,
but you can certainly do better. Originally, I thought about adding
another LiteralNode, but it would've been unnecessary complexity.
- Andreas