Change:
// Note, however, that we run on lots older linuxes, as well as cross // compiling from a newer linux to an older linux, so we also have a // fallback implementation to use as well. <del> #[cfg(any( target_os = "linux", target_os = "fuchsia", target_os = "redox", target_os = "emscripten" ))] #[cfg_attr(target_family = "wasm", allow(unused))] // might remain unused depending on target details (e.g. wasm32-unknown-emscripten) </del> <ins> #[cfg(any(target_os = "linux", target_os = "fuchsia", target_os = "redox"))] </ins> pub unsafe fn register_dtor(t: *mut u8, dtor: unsafe extern "C" fn(*mut u8)) { use crate::mem; use crate::sys_common::thread_local_dtor::register_dtor_fallback;

Discussion:
TLDR: Auto-dereferencing seems to break compiling to WASM with emscripten when threads are enabled? When compiling to WASM with threads enabled with emscripten I get the following error: <details<summaryFull error from rustc</summary</detailsI narrowed down the code causing this and it seems related to auto-dereferencing. This is the section of code, and you can see the type of parameter in the closure is multiple nested references ( or ). This code does not compile. <img width="852" alt="Screen Shot 2021-12-07 at 10 46 16 AM" src="https://user-"However, when I use a reference pattern to dereference the closure parameter, the code compiles and works as expected: <img width="861" alt="Screen Shot 2021-12-07 at 10 46 02 AM" src="https://user-"I also tested this theory by trying to compile the following code and it fails with the same error: Note that this error only occurs when compiling Rust with threads. You can view the repo with the full reproduction .
There is more talk happening . Apparently it is related to thread local storage, but it is unknown if it is a problem with rustc or emscripten. I also don't know why it specifically appears for me with auto-dereferencing
Sorry for the confusion. I don't think the parse issue you identified is related to thread local storage. It was just that when tlively was trying to reproduce your error, he had the same linker message that I get. And when I try your example program, I don't reproduce the parse exception, but instead get the thread local storage issue.
With the latest emscripten/llvm from git, the linking error with thread local storage is fixed. See
Now I can confirm that I get the error as well after upgrading my rust and emscripten: I previously didn't get that error with zackradisic's repository. I'm getting that with other simple examples as well, with no references in the Rust code. Versions in question: Interesting enough, the error does not occur on my when using the same version of emscripten above, but using an older v1.59 that I had complied previously on my machine: the error does occur with v1.60.

Seems like the error message comes from ?
doesn't seem to like the file that gets feed to $ wasm-validate target/wasm32-unknown- --enable-threads : error: invalid section code: 12 Running with --debug
I've put a few more details over at this which is a simple program that uses threads, and includes the wasm files for the working with the 1.59.0 compiler, and the broken wasm file from 1.60.0.
Running results in the following regression report for this issue: bash cargo bisect-rustc -vv --start=2021-12-06 --with-src -- build --release
Anyone have thoughts on the most likely patch from that merge to be the regression in question? at least mentions threads in the description.
I'm running into the same issue when compiling with threads on wasm32-unknown-emscripten target. I'm getting the generic error above about "pop from empty stack" when using with various binaryen tools: but a more actionable error message near the same offset when compiling Wasm in Looks like some potential ABI mismatch or miscompilation issue in some monomorphisation of .
just for reality check - this couldn't be related to the Wasm ABI feature, because that one only affects wasm32-unknown-unknown and not wasm32-unknown-emscripten, right?
I'm not sure the bisect start is right, because I'm getting the same issue when built with nightly-2021-12-06 too.
Tried to extract the full name of the function by index, but it doesn't help much:
Oh interesting, looks like this only happens after optimizations. Wasm binary built in debug mode is fine. So it's definitely some miscompilation or, at least, wasm-opt issue.
By playing with different optimisation options, narrowed it down a little further: it's the thread-local init callback in (I guess the latter). That said, it might just happen to be the first thread-local that parsing is failing on.
This increasingly looks like an issue at the linking stage, because this same code compiled into individual cdylib instead of being linked with other C/C++, works just fine.