Unable to access arguments in eval inside an arrow method

[aneeshdk]

function f3(a) {
    b = () => eval("arguments[0]");
    print(b()); // Should print 1
}
f3(1);

This throws an error saying arguments is undefined

[j-wing]

I'm taking at look this (with permission/guidance from @ianwjhalliday :) ). This is what I have so far.
Using a non-arrow function with the arrow function's body works fine, and removing the eval works fine. The following also fails with a ReferenceError:

function f1(a) {
  var arguments = [12345];
  var b = () =>eval("arguments[0]");
  return b();
}
print(f1(1));

But this works as expected:

function f1(a) {
  var argument = [12345];
  var b = () =>eval("argument[0]");
  return b();
}
print(f1(1));

@ianwjhalliday suggested I look at the bytecode that gets generated. If I do that, it looks like in all the cases that work, the following two lines of bytecode get generated inside of the outer function:

LdHeapArguments      R8
ProfiledInitLocalFld arguments = R8 #0 <0>

whereas the breaking cases are missing either the latter or both of those lines in their output. In the original example and my example, both are missing. If you put, e.g. print(arguments) somewhere in the outer function, you get the first without the second (and it still breaks, because the name doesn't get defined).

From my (very limited) understanding of the bytecode generator, it seems like the problem is that the bytecode generator needs to define the arguments field in the parent scope. If it sees a compile-time known reference to arguments, or sees an eval, either in its own scope or in a non-arrow function child-scope, it loads arguments with LdHeapArguments and then defines the field (since it may be referenced dynamically from within eval). But, the bug is that if the child function is an arrow function, it doesn't emit those two instructions automatically if it sees an eval from within the child. This bug might have happened since arrow functions don't have their own arguments object, unlike normal functions?

If you use eval in the parent scope before the arrow function, that forces the bytecode generator to emit those two instructions above - if I add in an eval("arguments") right before the definition of b in the first case, it works as expected in both my example and the one provided in the issue.

I'm not 100% sure why it fails in the example I provided. I do see that it never actually defines the arguments variable (with ProfiledInitLocalFld) - it just keeps it in a register.

Does this all sound right, so far? If so, it seems like we just need to get the arrow function case to work like the non-arrow case and emit those two instructions if there's an eval in a child's arrow function. Unfortunately, I have no idea how to do that.

[ianwjhalliday]

Yep, this is on the right track. Sounds like we might not be propagating an AST node flag about direct eval calls from the arrow function to the parent function, or maybe not reconciling that with the appears of arguments in the parent.

I don't recall off hand whether these flags are all strictly computed in the parser or if some are done in the bytecode generator. I suggest taking a look at PnFnc and FuncInfo structs to see if they have any flags that sound like they fit the bill, and then look at how those flags are computed.

[ianwjhalliday]

Additionally (first) you can examine where LdHeapArguments is emitted in ByteCodeEmitter.cpp and see what controls it. I suspect it will just be a flag which would then trace back to FuncInfo or PnFnc, but checking this would give you confirmation on my suspicions.