Add option to not demangle symbols #607
Conversation
|
Oh wow, CI is fully working again! So even if this PR isn't merged it has served a purpose, lol. |
39463ae to
e0e8e2e
Compare
|
So, I'm receptive to the core idea. Haven't evaluated the impl details closely yet. But I'm thinking and... it would be an obvious breaking change but I gotta ask: Is it actually our business to demangle symbols to begin with? 🤔 |
|
Well I think not tbh. We also have a weird hack to optionally add C++ demangling too, which seems silly to me. I mean, even if this crate does want to include demangling support, it could just be a separate function rather than baked in. But yeah, backwards compatibility. |
For the |
|
This feels somewhat similar to why |
|
Well different also in that there's lots of different ways to demangle symbols (depending on the language, etc). |
|
Isn't it a moot point? Even if we don't do it here, it would be a pretty bad user experience regression for rust backtraces to not demangle by default in std. I'm not sure mitigating that with extra tooling is a viable solution. Splitting that out from this library just means that theres extra cost paid - you need to run a demangling pass over the full backtrace after formatting or otherwise potentially incur extra allocations/time to do the demangling I suspect. |
|
Well yes, the default to std is unlikely to change. At least not in this way. I would however like to explore giving people more options (via build-std). And eventually it would be nice if it were possible to compile rust std applications without also having to compile a debugger into every single binary. But that's another issue. |
|
Oh, hm... this probably also needs some support in |
Ooh, this is a good point: you want to generate the symbol string once, because generating and regenerating it is going to be nasty. Ideally you'd have a formatter you can just point at a stdout instead of allocating at all. |
I've been playing with various backtrace related things in std, one of which is skipping demangling. And I thought this might be kinda useful more generally? Even if you want symbolization, you may want to bring your own demangler without paying the cost of the built-in one. Maybe this is a too niche scenario though 🤷.
So this is a new API for consideration. It simply adds a new
RawSymbolNametype. I considered just returning&[u8]but then thought that having some of the convinces ofSymbolNameis actually useful. And this is Rust so we can never have too many types.