Catch ParserException in IRFactory

[tuchida]

Closes #967
Errors in IRFactory have the following issues.

1. Parser$ParserException not caught.

   js> 1=1
   js: line 1: Invalid assignment left-hand side.
   js: 
   js: ^
   Exception in thread "main" org.mozilla.javascript.Parser$ParserException
   	at org.mozilla.javascript.Parser.reportError(Parser.java:340)
   	at org.mozilla.javascript.Parser.reportError(Parser.java:326)
   	at org.mozilla.javascript.Parser.reportError(Parser.java:321)
   	at org.mozilla.javascript.IRFactory.createAssignment(IRFactory.java:2325)
   

2. Wrong line position.

   js> var a = 1;
   var b = 2;
   const [c, c] = [3, 4];
   
   js> js> js: line 1: TypeError: redeclaration of const c.
   

IRFactory is re-parsing ASTs that have already been parsed by Parser, but the error thrown at that time was not handled properly.
So, I have fixed 0cd0e2b for 1. and 436d3f6 for 2.

[gbrail]

Thanks -- this looks really nice and I'm glad you did it.

I'm trying to also improve code coverage across the board, and from running "./gradlew testCodeCoverageReport" I can see that there are a few spots in IRFactory that we aren't testing. Specifically, there's some new exception-handling code around line 129 of IRFactory.java that doesn't seem to be hit by any of the tests. Would it be possible for you to come up with some sort of test code that would help us hit that spot?

Specifically, from looking at the coverage report, the part below in "transformTree" is new code, it seems pretty important, and it seems to be missing coverage.

    ScriptNode script = null;
    astNodePos.push(root);
    try {
        script = (ScriptNode) transform(root);
    } catch (Parser.ParserException e) {
        // Doesn't seem to have any code coverage here...
        parser.reportErrorsIfExists(root.getLineno());
        return null;
    } finally {
        astNodePos.pop();
    }

Thanks!

[tuchida]

@gbrail I added test to see if runtimeError was called ref. 6480350. However, the result of ./gradlew testCodeCoverageReport did not change. What should I do?

[gbrail]

Well there might be more for me to investigate, then, since I just replaced those non-covered lines with an AssertionError and the tests failed. So that tells me that the code coverage report could itself use some code coverage ;-) Given that, I'm happy to merge this as long as it doesn't conflict with your other big PR for IRFactory!

…

On Mon, Jul 15, 2024 at 3:29 PM tuchida ***@***.***> wrote: @gbrail <https://github.com/gbrail> I added test to see if runtimeError was called ref. 6480350 <6480350>. However, the result of ./gradlew testCodeCoverageReport did not change. What should I do? — Reply to this email directly, view it on GitHub <#1519 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I23VLFLIQNU5ICVQQCLZMREOPAVCNFSM6AAAAABK23B2RWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRZGU2DGNJXGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[p-bakker]

Hi @tuchida while rummaging though the backlog of issues, I ran into the following issues of which I wonder if this PR either resolved them or at least moves the needle somewhat:

• FAILED ASSERTION due to malformed destructuring syntax #405
• ClassCastException when compiling malformed destructuring expression #406
• const [y, y] = [] throws a TypeError, instead of SyntaxError #989
• Error with destructuring array assignment(?) #1187

[tuchida]

@p-bakker #405 was fixed. Others remained the same or had other errors.

[gbrail]

This is great and thanks for doing it!