Invalid URLs (absolute paths) in source maps in some cases #9837
Description
Summary
Source maps are supposed to contain only valid URLs in the sources array (either relative, or absolute with scheme). Emscripten sometimes emits absolute paths into that array instead, making them impossible to load by a browser.
Examples
For a file C:\Users\rreverser\Projects\temp-wasm\temp.c with arbitary content in a folder temp-wasm, I'm trying different formats for the filename.
Note that this is not a Windows-specific issue, and you'll get same results with Unix filepaths.
- Running
emcc ./temp.c -g4 -o temp.wasm(relative filename in the same folder):
{"version":3,"sources":["./temp.c"],"names":[],...- Running
emcc temp.c -g4 -o temp.wasm(same relative filename, but without explicit./):
{"version":3,"sources":["C:/Users/rreverser/Projects/temp-wasm/temp.c"],"names":[],...- Running
emcc ../temp-wasm/temp.c(relative filename with a folder):
{"version":3,"sources":["../temp-wasm/temp.c"],"names":[],- Running
emcc C:\Users\rreverser\Projects\temp-wasm\temp.c -g4 -o temp.wasm(absolute filename):
{"version":3,"sources":["C:/Users/rreverser/Projects/temp-wasm/temp.c"],"names":[],...Results
When a filename is relative but without a leading ./ or is specified as absolute, Emscripten outputs an absolute filename in sources, which is not a valid URL and can't be handled by DevTools. It could be valid if prefixed with file:/// specifier, but that's not an ideal solution.
The only case where Emscripten sources ends up being valid URL is when a filename is specified as explicitly relative (cases 1 and 3).
Then, Emscripten outputs a relative URL as well, which can be handled well by DevTools both in case of loading from filesystem as well as a static HTTP server.
More so, even though case 3 outputs a relative filename, it's not ideal.
Suggested solution
Emscripten should always compute relative URL out of the source map filename and the actual sources, and emit that in sources array.