Fix SINGLE_FILE with wasm2js

[kripken]

The relevant test was disabled internally, which is why I missed it when I triaged all the disabled tests (I was looking for decorators etc.).

Fix is pretty simple, the logic for when to use a mem init file was not aware of SINGLE_FILE. (There may be an even simpler way to rewrite that code, but let's wait until after fastcomp is removed for any major refactoring.)

Fixes #9380

[Beuc]

Hi. Recompiling zee.js with this fix works (no more external dependency) but the resulting zee.js does not decompress data anymore. I'll check whether this is a separate issue when time permits.

[Beuc]

I confirm, with 1.38.43 + this patch:

• Without -s SINGLE_FILE=1, zee.js requires libz.raw.js.mem but otherwise works.
• With -s SINGLE_FILE=1, zee.js is standalone but fails on ccall(gzread, ...), and I get weird errors such as TypeError: h[k[((Le + 36) >> 2)]] is not a function while running printf.
  So I suspect something is going wrong internally.

[buu700]

@kripken, I'm seeing a related issue: even when using --memory-init-file 0 as a quick workaround, it still fails in cases where a Content Security Policy blocks fetching data: URIs, whereas I would expect it to fall back to using tryParseAsDataURI as in this case.

[kripken]

@Beuc: that's odd, but I guess there's another issue then... if debugging it directly doesn't work, maybe running the test suite with that flag turned on would find some failure that is easier to debug.

@buu700: not sure I follow, but if there's a network access it should be practical to find where it's coming from?

[buu700]

There's no network access needed; SINGLE_FILE preferentially uses XMLHttpRequest to parse strings of base64 for performance reasons, then falls back to a JS implementation (tryParseAsDataURI) when that fails. A website's Content Security Policy is just one (I'd guess the most common?) reason XHR might fail.

The issue is that the fallback didn't seem to be working in my testing, which is odd because the code looks correct. I'll dig into this a bit more and see if I can figure out what's going on.

[Beuc]

This occurs with -02 and -s WASM=0.

Also, with zee's nodejs-based test suite, whatever value for SINGLE_FILE and/or WASM and/or 0, I get:
Assertion failed: you need to wait for the runtime to be ready (e.g. wait for main() to be called)
when ccall-ing gzcompress.
-- Is this related? Maybe it still expects some async loading to be completed, even with SINGLE_FILE? Given that there's no main in this project I'm not sure how to proceed :/

[buu700]

Whoops, sorry, you can disregard my comments here!

I totally misunderstood the problem because I didn't realize that with mem init method 0 and wasm2js asm.js no longer had a separate mem init file. Turns out this last issue with upgrading to the new backend was just an issue on my end (hadn't fully handled that asm.js no longer initializes synchronously).

[kripken]

@Beuc: SINGLE_FILE doesn't mean synchronous compilation. There is a separate flag for that with wasm, WASM_ASYNC_COMPILATION=0.