I may not be able to help much with the pthreads-related tests, but I can help with the other two!
Feel free to just disable these, I think that asm! is incompatible with emscripten and forever will be (same true for webassembly I believe)
Yeah right now all these tests start with // ignore-platform for a bunch of platforms that don’t have jemalloc compiled. The situation isn’t that great here, and ideally tests wouldn’t try to use jemalloc at all!
In my opinion the best course of actions about that pthreads problem is to force single-threading by modifying the functions within libstd/sys and making them either do nothing or return an error, so that pthreads isn’t used at all.
Then ignore all tests that require a thread to be spawned.
Would that be ok? I don’t think any other solution will come any time soon.
I’d personally prefer to avoid stubbing out std::thread primitives for single-threaded ones and instead just proxy error codes up through the normal pathways (e.g. pthread_create should return an error, right?).
I’d be fine adding // ignore annotations for now, but we may be adding quite a few…
The problem is that it doesn’t :-/
And it’s not just pthread_create. All mutexes and rwlocks (and maybe also TLS), even when used in a single-threaded environment, also straight up crash when you lock them.
The #[repr(packed)] issue is probably related to https://github.com/rust-lang/rust/issues/27060
Emscripten just assumes that all u32s and all u64s are 4-bytes aligned. If it isn’t the case there isn’t even a slow path, instead it just returns the wrong value.
Down to 7 failures right now, but it becomes more and more tedious.
(hopefully I’m not spamming this topic ; I use it as a kind of “meta-issue for emscripten”)
Only 2 failures left in debug mode: the repr(packed) issue and an unsupported SIMD operation.
In release mode around twenty failures, and all the new ones are caused by the strings-related problem I talked about above.
For the record the bug was actually due to the SimplifyStructRegSignatures pass, that converted some functions from the ret_type fn() signature to void fn(ret_type* output) but didn’t remove the pure attribute from them when doing so.
This led to some important function calls (like CStr::from_ptr) being stripped because LLVM thought they were useless.
Some updates. I’m hoping to push emscripten support across the finish line in the next 2 or so months. That is, for the project to distribute emscripten-targetting compilers and stds (whether they contain awful bugs is another matter).
The short term plan is for kripken to port emscripten’s LLVM branch forward to the same merge-base as ours, then for us to rebase onto their branch. We don’t have any immediate plans to upgrade LLVM, but in the future we’ll have try not to do it too often, because each time will force emscripten to upgrade as well. Likewise we’ll have to upgrade when they do, but they don’t anticipate needing to either. And we’ll have to tolerate temporary breakage of our emscripten support if it gets difficult to do it simultaneously. It could end in disaster. Who knows.
Once we’re on their LLVM, distributing emscripten bins is mostly a matter of turning some knobs on the CI.
In the longer term, kripken is very keen on creating a MIR->wasm backend for Rust, bypassing LLVM. If it works out then it could open up a lot of really interesting possibilities.
@tomaka is the best way to compile for emscripten still to use my ‘emscripten’ branch or do you have something more up to date? I’ll aim to rebase it onto Rust master soon.