It is way too hard to avoid including panicking and formatting infrastructure code

[fitzgen]

Even though panicking just translates into a trap without any diagnostic messages, we still include tons of being_panic_fmt etc type code. This has a huge code size footprint: ~75% of my code size after wasm-gc!

I had to write wasm-snip pretty much just for removing panicking and formatting infrastructure. But that is just a stop-gap, not a solution: it is fragile and manual.

[est31]

You could theoretically install a panic hook. Which is what I have done in one of my wasm projects in order to be able to find out what the panic was about.

[pepyakin]

My experience (although it is more -emscripten like) is that changing panic_fmt to something that doesn't touches it's args and building with LTO will remove most of the Display/Debug machinery and data from segments

However, there was still problems: sometimes this strings wasn't removed despite the fact panic_fmt was almost empty and "Arguments" parameter was dead.
As I can remember, I managed to solve this issue by running additional LLVM passes: deadargelim and some globals cleaning pass, over the final .ll file.

As far as can tell that wasn't emscripten fault.

[fitzgen]

You could theoretically install a panic hook. Which is what I have done in one of my wasm projects in order to be able to find out what the panic was about.

Can one change the panic hook without resorting to unstable features?

[est31]

@fitzgen yes, the panic hook API is stable: https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html

Generally I don't object to an option that allows you to turn off all panic related things but there should be an option to keep the panic machinery, especially as we can't emit any source maps on the unknown target yet. I know this is a bit hard given that cargo can't recompile std :/.

[fitzgen]

Generally I don't object to an option that allows you to turn off all panic related things but there should be an option to keep the panic machinery, especially as we can't emit any source maps on the unknown target yet. I know this is a bit hard given that cargo can't recompile std :/.

Crate authors could optionally set the panic hook based on a cargo feature.

If setting a custom panic hook really does get rid of all this bloat, then we should document how to do this somewhere and then close this issue.

[fitzgen]

Oh, and devtools show the disassembly, and if you have the "name" section (-g or debug = true), also show function names, which should help for debugging.

[est31]

@fitzgen I'm aware. They don't show the file name and line though.

[est31]

If setting a custom panic hook really does get rid of all this bloat, then we should document how to do this somewhere and then close this issue.

There are two mechanisms:

• setting the panic_fmt lang item. This does allow you to get rid of most of the panic formatting machinery (that's why it is used in an embedded framework as well) . It requires #[no_std] and right now it also requires nightly.
• the panic hook mechanism through the std::panic::set_hook function. This one doesn't really optimize out anything. I guess because the hook needs to changed during runtime :).

To make the first option work on stable, @japaric has written RFC 2070, but it still has to be implemented (tracking issue).

We can't really use this as we are no #[no_std] application. Maybe we could make the compiler allow later #[panic_implementation] invocations to override earlier ones somehow with a smart trick^TM. In order for this to work, LTO still needs to be able to optimize out the now dead code. Maybe this is not really possible. No idea. However, if xargo gets integrated into cargo, we can finally compile the entirety of libstd with panic=abort which would be the best resolution to this entire question.

[koute]

However, if xargo gets integrated into cargo, we can finally compile the entirety of libstd with panic=abort which would be the best resolution to this entire question.

I feel like having xargo integrated into cargo would solve a few of our other problems and points of contention too.

In the meantime I guess just going #[no_std] is going to be the best bet in getting the tiniest code footprint? Well, that or manually sniping parts of the .wasm file.

[mgattozzi]

@fitzgen I'm still working on #12 but once it lands if that does work we should add it there as a resource. Even a whole section on reducing binary size would be good.

[pepyakin]

However, there was still problems: sometimes this strings wasn't removed despite the fact panic_fmt was almost empty and "Arguments" parameter was dead.

It seems that it is also issue for wasm32-unknown-unknown target.
I've created an issue rust-lang/rust#47526.

[gamozolabs]

I'm so glad so many people are having these issues. I've been working on an RFC for a while (since December) on making a fmtless panic, as it is crazy that the core of the language (panic) requires one of the most bloated parts of core. I didn't really work on the RFC seriously as I thought I was the only one with this issue and it wouldn't go anywhere.

I'll start to prioritize it.

Currently the model is to have an opt-in fmt-less panic routine, perhaps just provides source file and line number (which for embedded targets is glorious debugging as is).