-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Disable unwinding for emscripten again #95950
Disable unwinding for emscripten again #95950
Conversation
Thank you for submitting a new PR for the library teams! If this PR contains a stabilization of a library feature that has not already completed FCP in its tracking issue, introduces new or changes existing unstable library APIs, or changes our public documentation in ways that create new stability guarantees then please comment with |
r? @nagisa (rust-highfive has picked a reviewer for you, use r? to override) |
|
Given that this is not the first time this default changes, I think we should have a write-up detailing a final decision and stick with it, instead of switching it back and forth every time the upstream project releases a new version. |
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.
LGTM, but lets wait the final decision on that problem
From my limited sleuthing: |
ccf0ba8
to
d373daa
Compare
This comment has been minimized.
This comment has been minimized.
d373daa
to
5ac753d
Compare
This comment has been minimized.
This comment has been minimized.
I'm going to nominate this for a T-compiler discussion. I think it is a correct thing to disable unwinding here, but I worry that doing so will break somebody's CI or something. Probably is worth it over a target that doesn't work at all, but also if we make a decision like this now, I feel like we should make it such that it is permanent. That is, we would commit to |
5ac753d
to
4a51f3c
Compare
rust/compiler/rustc_target/src/spec/wasm_base.rs Lines 83 to 87 in 2fa9789
I don't think committing to never ever having any form of unwinding for the Emscripten target makes sense, given that Rust doesn't commit to that for the other Wasm targets; once the Wasm exception handling proposal is finalized and stabilized everywhere, it can be used to implement unwinding. A weaker commitment which I think does make sense is that unwinding won't be implemented with any mechanism other than native Wasm exceptions—Emscripten's homegrown exception handling doesn't provide a API that Rust can rely on. |
This comment has been minimized.
This comment has been minimized.
Another option is to gate WebAssembly unwinding behind an |
4a51f3c
to
e791894
Compare
This comment has been minimized.
This comment has been minimized.
e791894
to
2caadf4
Compare
This comment has been minimized.
This comment has been minimized.
358bfc5
to
cb316c9
Compare
832e4f5
to
7406384
Compare
@rustbot ready |
This comment has been minimized.
This comment has been minimized.
00726cb
to
e88d5fe
Compare
☔ The latest upstream changes (presumably #97512) made this pull request unmergeable. Please resolve the merge conflicts. |
e88d5fe
to
37af9e0
Compare
☔ The latest upstream changes (presumably #97939) made this pull request unmergeable. Please resolve the merge conflicts. |
37af9e0
to
de9f48f
Compare
This should not be merged until the discussion around #97888 is resolved. |
☔ The latest upstream changes (presumably #97968) made this pull request unmergeable. Please resolve the merge conflicts. |
de9f48f
to
16140ab
Compare
16140ab
to
8a3e9f2
Compare
☔ The latest upstream changes (presumably #98037) made this pull request unmergeable. Please resolve the merge conflicts. |
Hi, I work on Emscripten and have historically worked on the Emscripten beckends in Rust, too. I am the one who previously enabled unwinding for the Emscripten target. From briefly looking at the issues that motivated this, it looks like the reporters were trying to use versions of Emscripten that use versions of LLVM that are incompatible with Rust's version of LLVM. In other words, I think the root problem here is a lack of documentation or automation about what version of Emscripten should be used with Rust, not that there is an actual bug with Emscripten or Rust. |
No, this wasn't an LLVM compatibility issue as far as I can tell, this was due to a change in Emscripten's |
Sure, but the principle is the same. Using Emscripten versions from before that change to Emscripten's |
I would think that the "correct" fix would be to rely only on APIs that the Emscripten project makes stability guarantees for, so users don't need to be bound to a specific version. |
I agree that that would be even better, but Emscripten does not currently make stability guarantees for anything beyond the basic C ABI, so unfortunately that is not realistic right now. We're aiming to stabilize our C++ ABI soon, which would include libunwind, but it is not stable yet. Relatedly, we would like to stabilize a dynamic linking ABI soon, but again, that's not stable yet. |
Unwinding on
wasm32-unknown-emscripten
seems to be broken again, so this PR disables it. Undoes 62c3443, fixes #85821, redux of #89762 which was abandoned by its author.