-
Notifications
You must be signed in to change notification settings - Fork 32
Cannot Assign Arrow Function Macro #63
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
Comments
Hi, and thanks for your bug report. I haven't looked at this project's code in a while, so I'll talk through my thoughts: That error comes from esvalid, which is the package used internally by the compiler here to sanity-check any AST before it's fed to escodegen for code generation, because escodegen doesn't do validation. I'm doing this validation because writing macros that construct estree is complex enough as-is, so I'd like to catch and display errors early, for users' benefit. However, esvalid hasn't been updated for a long time, so it doesn't support newer estree spec additions, such as arrow functions, even though escodegen can generate code for them. So in a792d03 I introduced this filter which is supposed to ignore esvalid errors relating to nodes that it doesn't support. It's not ideal, but the intention is to ignore errors with the unsupported new stuff, while retaining useful errors for estree nodes which validation is supported. These are the errors for your code, before filtering:
It looks like when an My error-filter is based on the false assumption that estree would only report an error for the unrecognised estree type in such cases. I'm leaning toward fixing this by removing esvalid altogether. It is badly out of date, and it's clear that filtering out its errors is more cumbersome than I expected. That would mean invalid estree would be passed to escodegen. That means it may generate invalid JS, or accidentally generate valid JS for invalid estree. Those problems would not be caught at compile-time. But at least then valid programs like yours would be accepted. I may get around to that at some point. If you get to it first, I would welcome a PR. In a perfect world, esvalid (or a fork) would support the full and current estree spec, and we could validate it all. But that would be quite a lot of really boring work. |
My arrow function macro is as follows:
I show the Ecmascript it produces with:
And I show the AST representation with:
When I run :
I get:
When I showAST I get:
Looks good to me. But when I go live with it:
I get:
Any ideas?
Kevin
The text was updated successfully, but these errors were encountered: