Question on scoping and NativeCall binding

37 views
Skip to first unread message

Joseph Jackson

unread,
Dec 16, 2021, 9:35:42 AM12/16/21
to mozilla-rhino
I've run into an issue in a forked version of rhino (1.7R5) where compiled mode and interpreted mode have a difference in behavior related to nested function scope that is causing some issues. 

I am trying to figure out if there is a bug in rhino, our code, or if I just don't understand how the NativeCall scope is used for nested functions. If someone could even help me with how to test this (compiled vs interpreted) in pure rhino that might help. I have tried using the rhino command in the terminal but can't figure out how to check the scope at runtime. 

Issue in Compiled mode:
When you have a function nested within another function the scope bound to the outer function is changed to NativeCall. In interpreted mode, this doesn't happen. I checked the bytecode and see we are creating the NativeCall scope and binding it to the main function because of code in Codegen which checked the hasVarsInRegs. 

here is where I believe that is set.
hasVarsInRegs = !fnCurrent.fnode.requiresActivation(); 


Here is an example to reproduce.
function first() {
    <breakpoint> // I am able to check the scope here 
    function second() {
        var a;
    }

    second();
}


Thanks in advance for any help!
Joe

P

unread,
Jan 26, 2022, 2:53:55 AM1/26/22
to mozilla-rhino
I'd first write a piece of test code that passes in interpreted mode and fails in compiled mode on your forked 1.7R5 version.

Once you have that, I'd run it against the official 1.7R5 version, to see if you get the same behavior there. If yes, then the 'issue' isn't related to your fork, if no it is related to your fork.

If you can reproduce it on the official 1.7R5 version, I'd next try to run the test against 1.7.14 (latest release) to see if it can still be reproduced there. If yes and you feel it's an issue, feel free to file an issue on github.com/mozilla/rhino with your testcode attached

Reply all
Reply to author
Forward
0 new messages