Legacy hoisting for `function arguments() {}` still not correct?

[anba]

refs: #815, #889, #891

Per the current spec semantics:

function f(a = () => arguments) {
  print(arguments);   // Print [object Arguments]
  print(a());         // Print [object Arguments]
  { function arguments() {} }
  print(arguments);   // Print function arguments() {}
  print(a());         // Print [object Arguments]
  
  delete arguments;
  print(arguments);   // Print [object Arguments]
  print(a());         // Print [object Arguments]
}
f();

Explanation:

1. function arguments() {} is an applicable legacy block-scoped function, because it can be replaced with var arguments without causing an early SyntaxError, and arguments is not a parameter name (B.3.3.1 Changes to FunctionDeclarationInstantiation, step 1.a.ii).
2. B.3.3.1 Changes to FunctionDeclarationInstantiation, step 1.a.ii.2 does not create a binding in varEnvRec, because the function name is "arguments".
3. 9.2.12 FunctionDeclarationInstantiation, step 28 also doesn't create a binding for "arguments" in varEnvRec.
4. So when B.3.3.1 Changes to FunctionDeclarationInstantiation, step 1.a.ii.3.f is executed, fenvRec doesn't have a binding for "arguments".
5. That means 8.1.1.1.5 SetMutableBinding, step 2.b creates a deletable binding.

Maybe we just need something like this in B.3.3.1:

1. If instantiatedVarNames does not contain F, then
   1. Perform ! varEnvRec.CreateMutableBinding(F, false).
   2. If F is not "arguments" or argumentsObjectNeeded is false, let initialValue be undefined.
   3. Else,
      1. Let initialValue be ! envRec.GetBindingValue(F, false).
   4. Perform varEnvRec.InitializeBinding(F, initialValue).
   5. Append F to instantiatedVarNames.

And two nits in B.3.3.1 Changes to FunctionDeclarationInstantiation:

• Step 28 -> Step 29
• Typo: initializedBindings-> instantiatedVarNames.

[anba]

This test from test262 also asserts the wrong thing:
https://github.com/tc39/test262/blob/443b15e43e8c497b2edcf8c064b11fd7c1ad67fc/test/annexB/language/function-code/block-decl-func-skip-arguments.js#L34

[anba]

This test from test262 also asserts the wrong thing:
https://github.com/tc39/test262/blob/443b15e43e8c497b2edcf8c064b11fd7c1ad67fc/test/annexB/language/function-code/block-decl-func-skip-arguments.js#L34

[leobalter]

cc @rwaldron ^^

[leobalter]

cc @rwaldron ^^

[littledan]

I'm not so happy with how complicated it turns out to support legacy hosting of functions named argument. Maybe we should just consistently skip this hoisting, as I guess were the semantics at some point recently.

[littledan]

I'm not so happy with how complicated it turns out to support legacy hosting of functions named argument. Maybe we should just consistently skip this hoisting, as I guess were the semantics at some point recently.

[allenwb]

@littledan
I'm with you. Legacy FiB supports solely to not break existing code that is interoperable among major browsers. If there is evidence that not hoisting functions named arguments does not result in significant breakage then we should add it the complexity. The rules for binding arguments is already too complicated.

[allenwb]

@littledan
I'm with you. Legacy FiB supports solely to not break existing code that is interoperable among major browsers. If there is evidence that not hoisting functions named arguments does not result in significant breakage then we should add it the complexity. The rules for binding arguments is already too complicated.