constant-folding: Fix some literal types used in .join(), closes #612#613
Conversation
|
Lint is failing, but if I e; I fixed just the lines i changed, looks like that did it ✌️ |
b820250 to
481d9f9
Compare
|
@goto-bus-stop What about people using template strings like |
|
Ah yes, that's quite simple. Thanks for the suggestion! |
| return `/${el.pattern}/${el.flags}`; | ||
| } | ||
| return el.value; | ||
| if (t.isNullLiteral(el)) { |
There was a problem hiding this comment.
IMO, we can do path.evaluate(el) and deopt.
If its gonna be killing performance which in most cases should not be a problem since the path would already be cached during the traversal phase.. Thoughts?
There was a problem hiding this comment.
You mean doing evaluate instead of all the is* checks?
e; The only problem I can see is that there's no access to the path in these replacement functions, so we'd need to pass it in somehow…
| return el.value; | ||
| } | ||
| if (t.isTemplateLiteral(el) && el.expressions.length === 0) { | ||
| return el.quasis[0].value.cooked; |
There was a problem hiding this comment.
|
Thanks! Looks good to me. Can you address the pending comments? |
31d9caf to
aa4f987
Compare
|
Added a commit to use |
|
LGTM. Looks like formatting issues on CI. you can fix it with |
|
Oops, should've checked lint before committing. Thanks for the heads-up |
The
.join()inlining function was checking forisLiteral()on each array element, and then using the element's.value. Some literals don't have.values though: null literals, regexp literals and template literals.This patch fixes
.join()ing regexp literals and bails out of joining template literals entirely.Null literals already did the right thing despite not having a
.value, because.join()appears to treatundefinedandnullthe same.