As a followup to #11319 we have a lot of potential cleanup of emscripten to do now that fastcomp is no more.
One thing to consider: do we want to make backporting/cherrying picking easy(er) for while). Should we hold off large refactors for a while for this reason? It seem like there will be enough pure-deletion PRs to keep us going for while :)
List of cleanup work:
src/ inside !WASM_BACKENDnot WASM_BACKENDWASM_BACKEND completely.WASM? (even with -s WASM=0 we set WASM to 1 and set WASM2JS, in verify_settings. so WASM == 1 all the time in tests etc.)Cleanup PRs should mention "See #11860" (this PR).
I agree deletion PRs are a good starting point. That's low-risk, and enables more stuff later.
I don't think we should try to make backporting easier, as there seems little benefit. (If backporting is important to someone, would be good to hear about that, and how we can work together on it.)
I think we should coordinate those deletion PRs in this issue, to avoid stepping on each others' toes and getting lots of merge conflicts. For example: I can start with the JS code src/* - ?
Sounds good. Why don't we all work on the list above and put your name on a list item if you are going to start work on it? I am personally going to try to avoid the temptation to just do all of them right away :) (Mostly since I think it could suck all my time for the next month!)
Would removing all of the custom (non-wasm-ld) linking code fall into this, or are there still things to fix for that?
Yes, although sadly we still have at least one customer who wants to do bitcode linking, which currently is not possible with wasm-ld so for now we need to "link-to-bitcode" path to stay alive I think.