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.

Sign up for GitHub

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

Jump to bottom

Syntatically wrong callback function validation check succeeds even though it would fail in a browser. #101

Open
krishnanand opened this issue Jun 6, 2018 · 2 comments
Open

Syntatically wrong callback function validation check succeeds even though it would fail in a browser. #101

krishnanand opened this issue Jun 6, 2018 · 2 comments

Comments

@krishnanand
Copy link

This is my test case

code = 'function callbackFn(activate, options) {\n  if (true)\n}' # The if block does not have any brackets or any body.
parser = slimit.parser.Parser()
ast = parser.parse(code)
nodes = list(ast)
root = nodes[0]
return isinstance(root, slimit.ast.FuncDecl) . # This returns True

Am I doing this incorrectly? If yes, how do I validate the string?
@krishnanand krishnanand changed the title Syntatically wrong callback function validation check succeeds Syntatically wrong callback function validation check succeeds even though it would fail in a browser. Jun 6, 2018
@metatoaster
Copy link

This is definitely a bug, and thank you for finding this issue so I can fix it in my fork.

metatoaster added a commit to metatoaster/calmjs.parse that referenced this issue Aug 7, 2018
@metatoaster
Actually correct the ASI generation procedures
f14c9df 
- Drop the extraneous auto_semi rule, as it turns out that rule is
  **never** hit due to it being effectively replicates the unmatched
  production condition (through auto_semi then error).
- However, on the case where the SEMI is produced through the error
  handler after an error condition that is actually an error, if the
  production stack is just that freshly generated SEMI, if will be
  immediately consumed and used by the empty_statement production rule,
  then the previously erroring token is yielded again, restarting the
  cycle thus that's the real cause behind the infinite loop as reported
  in rspivak/slimit#29.
- However, if the auto generated SEMI tokens are correctly marked, and
  update the existing rules to make use of that token, the immediate
  consumption of the token cannot happen if an empty statement does NOT
  include the auto generated SEMI token (which has been done by creating
  a new AUTOSEMI token type), the condition which the immediate
  consumption of a token to result in the error token can no longer
  occur.
- Removed the seen before token hack.
- Moved all the conditions for which AUTOSEMI token is generated to the
  lexer auto_semi method.
- This also completely eliminates the incorrect production of statements
  that only has SEMIs but not the ASI equivalent, such as the case with
  ``if`` or ``for`` statements as per 7.9.2 of the ECMA-262 5.1 spec,
  which is reported in rspivak/slimit#101.
metatoaster added a commit to metatoaster/calmjs.parse that referenced this issue Aug 7, 2018
@metatoaster
Actually correct the ASI generation procedures
486626d 
- Drop the extraneous auto_semi rule, as it turns out that rule is
  **never** hit due to it being effectively replicates the unmatched
  production condition (through auto_semi then error).
- However, on the case where the SEMI is produced through the error
  handler after an error condition that is actually an error, if the
  production stack is just that freshly generated SEMI, it will be
  immediately consumed and used by the empty_statement production rule,
  then the previously erroring token is yielded again, restarting the
  cycle thus that's the real cause behind the infinite loop as reported
  in rspivak/slimit#29.
- However, if the auto generated SEMI tokens are correctly marked, and
  update the existing rules to make use of that token, the immediate
  consumption of the token cannot happen if an empty statement does NOT
  include the auto generated SEMI token (which has been done by creating
  a new AUTOSEMI token type), the condition which the immediate
  consumption of a token to result in the error token can no longer
  occur.
- Removed the seen before token hack.
- Moved all the conditions for which AUTOSEMI token is generated to the
  lexer auto_semi method.
- This also completely eliminates the incorrect production of statements
  that only has SEMIs but not the ASI equivalent, such as the case with
  ``if`` or ``for`` statements as per 7.9.2 of the ECMA-262 5.1 spec,
  which is reported in rspivak/slimit#101.
@metatoaster metatoaster mentioned this issue Aug 7, 2018
Merged
@metatoaster
Copy link

If you are still trying to make this work and haven't solve this with another library yet because you want something like slimit, I just made a release of my fork of slimit (as calmjs.parse-1.1.0) and this now works also:

>>> from calmjs.parse import es5
>>> code = 'function callbackFn(activate, options) {\n  if (true)\n}'
>>> es5(code)
Traceback (most recent call last):
...
calmjs.parse.exceptions.ECMASyntaxError: Unexpected '}' at 3:1 after '\n' at 2:12

You may just simply catch SyntaxError as ECMASyntaxError inherits it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@metatoaster @krishnanand