Template Literal support

[p-bakker]

First of all: tnx for @anba for the initial implementation in #81

This PR rebases the work done in #81 and updates it to be compatible with the latest

This is a Draft PR, just to get it out there and get feedback. So, any feedback appreciated :-)

Left to be done:

1. fix 3 breaking tests from Test262 (see Question: ScriptableObject implements the Map interface, but the Map.get impl. doesn't take into account the ScriptableObject prototype #903, Release 1.7.13 #734 (comment) and https://groups.google.com/g/mozilla-rhino/c/StUgOIRoOFY)
2. formatting (rather not do some of the formatting work already done in Refactor SlotMap and Slot classes #896)
3. code review

closes #243
closes #325
closes #773
closes #294

Enables: updating to a newer version of Test262 (see 6c1582a, #817)

[p-bakker]

One of the failing tests is related to this within a function executed in strict mode: https://github.com/tc39/test262/blob/main/test/language/expressions/tagged-template/call-expression-context-strict.js

Am wondering if this is just something that Rhino just doesn't support (yet) in general, that this referenced within functions in strict mode should not be a reference to globals.

If so, I can just mark this test to be excluded and then I'm down to 2 failing tests, which are both the same freezing issue

[tonygermano]

closes #325
closes #773
closes #294
closes #434

Edit: Looks like maybe I can't link these since I'm not the author. It should link them all if you update the first comment to list them one one per line.

[gbrail]

There are lots of problems with strict mode, unfortunately. I think it's fine to disable individual tests if they don't work in strict mode.

[gbrail]

This is a lot of work but it's looking very promising. Probably the main thing I'd do is look at the code coverage from "./gradlew jacocoTestReport" and see that the new aspects of the code are being tested.

[p-bakker]

Thx, I'll give that a try

…

On Fri, May 21, 2021, 7:28 PM Greg Brail ***@***.***> wrote: This is a lot of work but it's looking very promising. Probably the main thing I'd do is look at the code coverage from "./gradlew jacocoTestReport" and see that the new aspects of the code are being tested. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#904 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGADHK4MIRTRIDZUXANL43TO2J2VANCNFSM45I6PTYA> .

[p-bakker]

Is it correct that jacocoTestReport doesn't generate any output if there are failing tests? Cause I'm not getting any output from jacoco (but I have some failing tests)

Found an issue in CodeGen wrt Escape Sequences which only manifests itself when not running at optLevel -1

[gbrail]

Probably not -- the tests probably have to pass to get coverage.

…

On Fri, May 21, 2021 at 12:30 PM Paul Bakker ***@***.***> wrote: Is it correct that jacocoTestReport doesn't generate any output if there are failing tests? Cause I'm not getting any output from jacoco (but I have some failing tests) Found an issue in CodeGen wrt Escape Sequences which only manifests itself when not running at optLevel -1 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#904 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I24IIM2BJPOBHHWHOATTO2YHDANCNFSM45I6PTYA> .

[p-bakker]

Update on where things are with this PR:

1. All formatting changes spotless desired have been applied
2. There are currently 2 failing tests in Test262:
   1. one related to strict mode. Commented out in test262.properties, as it depends on Bound functions leak global scope into strict functions  #442
   2. one related to proper freezing on Objects in Tagged Templates. Commented out for now, but still needs to be fixed before this PR would be ready to merge
3. I ran the code coverage reports and these are the findings:
   1. One piece of code is not covered, imho due to Test262 not providing full coverage. Created Test missing for \u{10000} ... \u{10FFFF} in Template Literals tc39/test262#3001 for this. Also led me to create Support ES2015 unicode escape sequence additions  #917
   2. Some code paths related to parse exceptions aren't hit, like an unfinished Template Literal at the end of a file. Must these paths all be covered? I see similar exception handling code in other classes that also doesn't get coverage
   3. the ast/TaggedTemplateLiteral, ast/TemplateCharacters and ast/TemplateLiteral have stuff like .visitor(...) and .toSource(...) that aren't being covered. Should they? I see those methods are also not covered in BigIntLiteral for example
   4. Lastly, ast/TemplateLiteral has a couple of public methods the rounds out it's api nicely, but those methods aren't being called anywhere from the Rhino source. I didn't author these myself, they came from @anba's PR, so not 100% sure what to do... leave as is, remove or make sure they are covered with tests?

All in all, it's getting pretty close :-)

[p-bakker]

So, from my POV this PR is ready to merge!

As per #904 (comment), there's one failing test (due to general strict mode issues in Rhino) and a few area's of code not covered by testing code, but those uncovered area's are also uncovered in similar classes.

[gbrail]

This looks good to me. I'm going to go ahead and merge it. Thanks!

[tonygermano]

I think there needs to be some kind of celebration for this one.

[dh-pt]

This ... is an amazing pr. Wow, thanks team.