Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Function declaration name is mistakenly treated as function code #1707

Open
ariya opened this issue Jan 3, 2017 · 4 comments
Open

Function declaration name is mistakenly treated as function code #1707

ariya opened this issue Jan 3, 2017 · 4 comments
Labels

Comments

@ariya
Copy link
Contributor

ariya commented Jan 3, 2017

(As reported by @michaelficarra and explained by @bakkot as case 14,15,18-25 in #1502).

Test case:

esprima.parse('function eval() {"use strict"; }');

Actual: An exception "Function name may not be eval or arguments in strict mode".

Expected: A valid syntax tree.


A similar test case:

esprima.parse('function static() {"use strict"; }');

Actual: An exception "Use of future reserved word in strict mode".

Expected: A valid syntax tree.


A reference for this in the specification is on Types of Source Code:

Function code is source text that is parsed to supply the value of the [[ECMAScriptCode]] and [[FormalParameters]] internal slots (see 9.2) of an ECMAScript function object.

While the formal parameters are part of the function code, the declaration name however is not.

@ariya ariya added the defect label Jan 3, 2017
@bakkot
Copy link

bakkot commented Jan 3, 2017

It's probably worth noting that all major engines also reject such programs, contra spec.

@bakkot
Copy link

bakkot commented Jan 3, 2017

Oh, and see old spec bug relating to this, which never got resolved.

@ariya
Copy link
Contributor Author

ariya commented Jan 3, 2017

@bakkot Confirmed. I checked the behavior of V8, SpiderMonkey, and ChakraCore.

It would be interesting to find out (1) the reason that most web browser's engine continues to violate the specification (compatibility etc) and (2) if there is any plan for those engines to start to comply to the specification in the future.

@ariya ariya mentioned this issue Jan 4, 2017
@bakkot
Copy link

bakkot commented Mar 30, 2018

The spec question has finally been resolved in favor of making a normative change to match the behavior in most implementations, including esprima. See tc39/ecma262#1158. I think this can be closed with no further action.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants