emscripten support broken by cargo file layout changes

[CryZe]

Moved over from: rust-lang/rust#38454

Looks like the compiler uses hashes as postfixes for the deps now. This messes with emscripten though, as the final "binaries" don't get copied out of the deps folder correctly anymore. Also the original names get baked into the JS files, so even if copied out correctly, they can't find each other anymore.

Uncaught could not load memory initializer aoc-66434e595ec0b4e8.js.mem

To clarify, the final JS binary is located in the target/asmjs-unknown-emscripten/release/ folder as aoc.js like intended. However there's no aoc.js.mem file like there used to be. That's because the deps are called aoc-66434e595ec0b4e8 now, so the compiler spits out the binaries with that name. However rustc only copies out the aoc-66434e595ec0b4e8.js as aoc.js, but not the mem file. But even if it copied out the mem file, it wouldn't be able to rename it, because the aoc.js looks specifically for the original name.

[CryZe]

Recently there has been a fix for .lib files on Windows (afaik) which were affected by this too, so a similar fix could be applied for this.

[alexcrichton]

Thanks for the report! The relevant code in Cargo is here, which specifically avoids passing -C extra-filename=... for some file types (dylibs and cdylibs). This means that the long hash at the end (-66434e595ec0b4e8 above) won't get thrown into the filename.

Even with that, though, the aoc.js.mem file still will not be present in target/asmjs-unknown-emscripten/release but rather inside .../release/deps. Cargo manually lifts files up from the deps folder to the ../release folder and it doesn't know about the *.mem files because rustc itself doesn't know about the mem files!

Is that a suitable solution here? Or is it also required to lift up the *.mem file as well?