Bump swc #9574
Bump swc #9574
Conversation
|
Even in release builds, there is a segfault now in the EnvReplacer, the stack trace does many Usually, this is only a problem (and has happened for a long time) in non-release builds. But only on Linux and Windows, macOS works fine. |
mischnic
force-pushed
the
bump-swc
branch
2 times, most recently
from
9109912
to
dd8513d
Compare
|
The same asset also works fine in a standalone Rust projects (with the exact code as the JSTransformer, just without the Node process). |
Not really an area I have any experience in, but a quick search shows that is possible to increase the stack size with some linker flags: https://www.reddit.com/r/rust/comments/872fc4/how_to_increase_the_stack_size/ Is that worth experimenting with? EDIT: read something else that mentioned threads on linux specifically have a smaller stack, maybe we need to increase the Rayon thread stack size (that's where this code is running, right?): https://docs.rs/rayon/latest/rayon/struct.ThreadPoolBuilder.html#method.stack_size |
|
I want to try bisecting which swc version introduced this, because not much changed regarding the AST depth So increasing the stack size would maybe just be a workaround until some future version. |
|
As it turns out, this also occurs in Deno and Turbopack: swc-project/swc#8840 |
mischnic
force-pushed
the
bump-swc
branch
2 times, most recently
from
9022329
to
214a0b2
Compare
|
Weirdly I couldn't reproduce even with And yeah it looks like you're right about stack overflows not reporting a back trace. I should have known better than to trust gpt lol. |
|
No, Github doesn't see it as a approving review... |
|
@devongovett when you have a moment could you review this PR? Normally I wouldn't bother with a ping but it's currently a blocker for us at Stripe. I think it's good to go it just needs an approving review. |
| @@ -594,7 +595,7 @@ impl Fold for ESMFold { | |||
| if self.in_export_decl { | |||
| self.create_export( | |||
| node.key.sym.clone(), | |||
| Expr::Ident(node.key.clone()), | |||
| Expr::Ident(node.key.id.clone()), | |||
There was a problem hiding this comment.
Just sharing what I shared in Discord here, it seems that the change arround AssignPatProp means that after visiting here it will visit into fold_binding_intent, this results in a duplicate export being added for exports of the form export const { Foo } = bar; in non-scope hoisting mode - this breaks at runtime.
This change fixed the issue for me, but not sure if there's some edge case that it might not be correct for. It would be good to start with a failing integration test.
diff --git a/packages/transformers/js/core/src/modules.rs b/packages/transformers/js/core/src/modules.rs
index 65235f3c3..bd13d10b6 100644
--- a/packages/transformers/js/core/src/modules.rs
+++ b/packages/transformers/js/core/src/modules.rs
@@ -598,9 +598,11 @@ impl Fold for ESMFold {
Expr::Ident(node.key.id.clone()),
DUMMY_SP,
);
+ node
+ } else {
+ node.fold_children_with(self)
}
- node.fold_children_with(self)
}
modules_visit_fn!(fold_function, Function);
Bump swc
This reverts commit d4dba2c.
|
@marcins @jondlm I fixed that problem, there's a new dev release published at https://github.com/parcel-bundler/parcel/actions/runs/9077140040/job/24942042946 |
Closes #9632
Closes #9607
There's a major breaking change, the LHS of assignments is now a special enum.
There's one place which I haven't been able to fix yet. Putting this up in case someone else wants to bump swc sooner rather than later for some reason