emscripten support broken by cargo file layout changes

[CryZe]

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.

Ping: @brson

[alexcrichton]

This is likely due to rust-lang/cargo#3102, not a rustc change itself. That tweaked how Cargo deals with the directory structure a bit, and namely assumes that if you hard link a "binary" to a new location it will continue working. Turns out that's not true for emscripten though!

[brson]

Thanks for the report @CryZe.

[RReverser]

I didn't try, but does this mean that Cargo will break source map support as well? (as in, will it rename .js.map file to hash-based too and debugger won't be able to find it?)

[RReverser]

Checked, looks the same - sourceMappingURL points to hashed filename and .js.map is not copied.

[alexcrichton]

@RReverser if this behavior is causing problems we may be able to alter Cargo's behavior as well to be more amenable to emscripten

[RReverser]

@alexcrichton Well at the moment I've submitted emscripten-core/emscripten#4936 to Emscripten, so it will be the only blocker to get separate memory init file in Rust, and also it seems to block ability to debug with source maps when building with Cargo.

Would you want to have a special Cargo behavior for .js.mem & .js.map or is there a more elegant solution to this?

[alexcrichton]

Awesome, thanks!

We may also want to have special support for this in Cargo. IIRC this is also an issue for Windows with *.lib files, so we may be able to fold all these solutions into one perhaps

[RReverser]

@alexcrichton I'm wondering if inverting folder copies would help (that is, for top-level target build in the debug/release folder with proper name first, and then copy to deps with currently hashed names.

Then, when you're looking for cached result, you still look for the hashed one in deps and extract with proper name.

[alexcrichton]

@RReverser that... sounds like a great idea!

[Mark-Simulacrum]

This looks like a Cargo issue, since as far as I know rustc itself doesn't really have any special logic along these lines. As such, I'm going to close; please refile there if this is still a problem.