-
-
Notifications
You must be signed in to change notification settings - Fork 225
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
Add mark eval scopes helper and deopt DCE fn unused params #371
Conversation
boopathi
commented
Jan 10, 2017
•
edited
Loading
edited
- (fixes babili is removing function arguments in scope of eval call #366)
- (fixes babili is removing variables in scope of eval call #367)
The helper attaches to the scope object directly instead of returning the list of scopes that contain eval. This is to avoid traversing the program twice - mangler, dce. |
Also, this now only deopts eval scopes for only a few transforms under the visitor |
`); | ||
|
||
const expected = unpad(` | ||
function a(b, c, d) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this work with nested functions too? i.e. making sure it doesn't mangle top-level vars either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added more tests
@@ -0,0 +1,52 @@ | |||
"use strict"; | |||
|
|||
const EVAL_SCOPE_MARKER = "evalInScope"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we use Symbol instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes. Will change. I was using scope.evalInScope
directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this is something that should be done on Babel level? So that you can just ask scope.hasDirectEval
or something along those lines.
/cc @hzoo
I think so too, but if we keep it in babel, it should be CORRECT rather than optimised for a few use cases. Like now, we don't recompute between multiple calls of If we implement this in babel, every call of |
Yeah, this brings us again to the usual issues of keeping track of proper state and revalidation. Just like we don't update bindings or certain path information right now after changing nodes. |
@@ -710,6 +715,10 @@ module.exports = ({ types: t, traverse }) => { | |||
traverse.clearCache(); | |||
path.scope.crawl(); | |||
|
|||
if (!isEvalScopesMarked(path.scope)) { | |||
markEvalScopes(path); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd love to merge this for now.
Just one suggestion — let's move isEvalScopesMarked
into markEvalScopes
(checking it within and returning if scope is already marked). That way API becomes simpler (markEvalScopes(path)
), there's less vars to exports, etc.
Another thing to consider is that markEvalScopes
operates on path, and hasEval
operates on scope. In an ideal world, that means these methods belong to those objects — path.markScopesWithEval
, scope.hasDirectEvals
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't put isMarked inside markEvalScopes because if something is changed after marking - we need to remark.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that means these methods belong to those objects — path.markScopesWithEval, scope.hasDirectEvals
Yes!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to implement them in Babel instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/cc @hzoo what do you think ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see inline
Merging for now. Later, we can implement this in Babel instead. |
@boopathi thanks for a speedy fix! |