[panic-persist] Implement compact version

[jamesmunns]

Right now, panic-persist stores a string, which can take a lot of space (kilobytes, potentially). It would be nice to have a version that just stores some kind of error code, or maybe a file/line number, perhaps tied to an enum, to reduce the required storage size down to just a few bytes.

However, right now panic machinery is very string based, so I'm not sure how I would do it.

Initial thoughts:

• Match on the string in the panic handler, assign unique error codes?
  • probably would require silly no_mangle shenanigans
• Maybe something like stlog, where strings are actually contained in the debug section, and just exist as an ID?
• Maybe provide an alternate panic function that takes an enum instead? Maybe provide an extension trait for persist_unwrap() or something?

[jamesmunns]

If the error is a &'static str, maybe I could just use the address of the string in .text?

[cr1901]

Maybe provide an alternate panic function that takes an enum instead? Maybe provide an extension trait for persist_unwrap() or something?

I like this idea, FWIW.

[jamesmunns]

@cr1901 The only problem with the extension crate trait is that it doesn't help if your libraries panic. But I guess most of the time the panic is going to be in your code, instead of the library. I guess we could have a default ENOREASON which can hint something in your dependencies (or core) panic'd.

[cr1901]

By the time LTO has had its say in the applications I develop, the only panic sources are Option/Result unwrap() and bounds check failure- both external. The idea is that somehow at compile time (haven't figured out how), extract the panic site, and print it as an 8-bit integer or the offending pc.

[cr1901]

@jamesmunns Let me rephrase my previous comment.

My theory is that even if libraries panic, the size of the applications where "panic-persist stores an error instead of a string" makes sense are those were it's very tractable to compare and contrast the Rust source of your applications and deps w/ emitted assembly.

There's no stable way to do this inline yet, but perhaps we could optionally extract the pc to send along with an error variant, so addr2line can be used?