Deprecate --keep-debug flag

[daxpedda]

Debug information is already controlled by Rustc/Cargo, but the reason this flag was introduced is to control debug information coming from the pre-compiled Std libraries, see #466.

This can now be done by the user instead in Cargo with the strip option, which is available since v1.59 (or directly with Rustc -C strip since v1.58).

Additionally, this will require no user action at all when v1.77 releases, which will strip Std's debug information automatically when no debug information is requested (e.g. the release profile), see rust-lang/cargo#13257.

This should significantly improve the stacktraces with the downside of significantly increased Wasm file sizes in release mode for users who don't strip debug information or are using Cargo versions below v1.77.

We might want to hold off merging this until Rust v1.77 release, which would be 21th March, but considering how close this is (13 days) I think its alright.

See #3483, which made this finally possible.
See #3698 for tracking other debug information related improvements.

Blocked on rustwasm/walrus#284 and a new Walrus release.

[Liamolucko]

Debug information is already controlled by Rustc/Cargo, but the reason this flag was introduced is to control debug information coming from the pre-compiled Std libraries, see #466.

Interesting, I didn't know that history.

This should significantly improve the stacktraces with the downside of significantly increased Wasm file sizes in release mode for users who don't strip debug information or are using Cargo versions below v1.77.

I didn't think debug info affected stack traces. At least at a first glance, browsers only seem to use the name section for that, which is already included without --keep-debug.

It should still be useful for actually debugging, though.

We might want to hold off merging this until Rust v1.77 release, which would be 21th March, but considering how close this is (13 days) I think its alright.

Yeah, this probably won't be getting included in a wasm-bindgen release until after that point anyway.

[daxpedda]

This should significantly improve the stacktraces with the downside of significantly increased Wasm file sizes in release mode for users who don't strip debug information or are using Cargo versions below v1.77.

I didn't think debug info affected stack traces. At least at a first glance, browsers only seem to use the name section for that, which is already included without --keep-debug.

Strange, it does improve the stack trace for me significantly.

[daxpedda]

So after some digging, I found that wasm-opt doesn't currently support support our DWARF output, for whatever reason. I opened WebAssembly/binaryen#6391 for that.

The main worry here is that wasm-pack suddenly stops working. This shouldn't be a problem as soon as Rust v1.77 hits, as then debug information will be stripped by default anyway.

I will update the PR when that happens.

[daxpedda]

This should significantly improve the stacktraces with the downside of significantly increased Wasm file sizes in release mode for users who don't strip debug information or are using Cargo versions below v1.77.

I didn't think debug info affected stack traces. At least at a first glance, browsers only seem to use the name section for that, which is already included without --keep-debug.

Strange, it does improve the stack trace for me significantly.

You are right, I had the C/C++ DevTools Support extension enabled, which is why I was getting better stacktraces.

[daxpedda]

Apparently wasm-opt still fails unless we use -Cstrip=symbols, I'm happy to still move forwards with this as it isn't really a wasm-bindgen issue.

WDYT @Liamolucko.

[daxpedda]

I'm unsure why wasm-opt fails in CI, seems to work locally for me ...

[daxpedda]

The issue was actually quite simple: Walrus generated empty custom sections even if no debugging information was available. wasm-opt apparently can't handle that.

I made a fix in rustwasm/walrus#284.