-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Formatting of std::backtrace::Backtrace #65280
Comments
+1 to all three points. I would accept a PR for this change. |
I'd like to take on this issue and make a PR for it. This is my first time taking on a PR for rust though, so is there anything you'd suggest outside of the Contributing guide? |
I think this requires edits in libstd ( Lines 269 to 323 in 437ca55
|
Thanks! I had already looked into it though, I meant more of general contribution to Rust 😄 |
How's this looking?
|
The trailing comma at the end looks wrong Could you share the |
Yeah I'm working on getting that out of there, I was starting with just modifying the And here it is prettyprinted:
|
You can get a lot of this for "free" if you make use of fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
f.debug_list()
.entries(backtrace.frames.iter().map(|f| DebugFrame(f)))
.finish()
} And in |
Oh that's a great idea, I had forgotten those helper methods were there in Debug. Thanks! |
Here's my fork with what I have so far for backtrace-rs. Now, the reason there was a trailing comma at the end was that the last frame had a IP of 0x0, and its symbol had no data. Do those need to be filtered out or is there a practical use for those? Also, the one thing left besides precision is getting the path properly, but before it was done by being passed in to BacktraceFmt. Do you have some suggestions for how I could get that into the DebugBacktraceSymbol in a more efficient way than just passing it down through the DebugBacktraceFrame and then down into the DebugBacktraceSymbol? |
So, I changed it back to the previous way of printing everything out, just with some added formatting, and a check to see if it's the first frame so it knows when to print a comma after a symbol's "map". The precision also works now, but there's a catch, since the formatter is passed down to the print path function the precision persists when printing out the path. Since |
My idea using precision might not end up working well... |
Actually.. Here's what it's doing now |
What about indent? |
Remove backtrace header text Fixes point 3 from rust-lang#65280 related to rust-lang#53487 This should probably be double checked by someone who works on fuschia because theres some extra fuschia specific output in `add_context` that is also removed by this change.
Add initial debug fmt for Backtrace Fixes the first point in rust-lang#65280 related to rust-lang#53487
@dtolnay @seanmonstar is this issue resolved? |
Probably! Of the points I posted originally:
|
Would adding the precision stuff later be considered a breaking change that violates std's stability guaruntees? |
IMO currently the only guarantee we're making about backtrace is that formatted with the normal Debug formatting ( |
@withoutboats I would maybe not even go that far? e.g. that we probably don't want to guarantee a specific implementation wrt to showing inlined functions and such. But maybe you mean that we will keep the format of the "raw" Debug display consistent with what it is today. I'd personally be unsure that I would want to stabilize even that -- I think if we're essentially stabilizing that I would rather stabilize accessor methods returning an iterator or something along those lines to avoid people parsing our output (and preventing any, even minor, changes as a result). |
This should probably be on the #72981 but: users are curently relying on that format to parse out info about the frames, because we don't provide a better API. We should not break that, at least until we have stable accessors. I agree that we should provide those APIs as well, but I wouldn't agree that it should block stabilizing backtrace. I just think we should be aware that users are currently, on nightly, relying on the format of the debug output. |
Ah, I was not aware that we knew of use cases that were doing that. I agree that we should not break them just because and certainly not before methods are added to replace functionality. I also agree it need not block stabilization. One thing that might be good to do is to add a method that explicitly keeps the current format or at least add a snippet to the Debug impl noting that we intend to keep it stable. |
Yea, my inclination is to not block stabilization on the filtering issue, users can already filter the frames themselves by parsing the output from the |
Have you guys settled on the precision idea or are you open to other approaches? Using |
My impression is that we're punting on the issue and instead focusing on making it possible for ppl to experiment with their own display formats by adding a |
On Fuchsia we use external symbolization, which means the file and line number are not resolved in the process itself. This allows us to capture backtraces without having to ship binaries containing debuginfo. We use a standard symbolization markup format across the platform, where each frame is typically printed on its own line. I'm not opposed to these changes on other platforms, but I bring this up to highlight that the Display/Debug formats of |
@tmandry is that implemented using the Rust standard tooling or some other way? Would be nice for development on this issue to have a minimal repro case, against which to test changes to Rust on. |
I'd like to propose some changes to formatting of the
Backtrace
type introduced in #53487.Don't include newlines in the default
Debug
output. I personally find it pretty jarring when looking at the debug output of an error where everything is on the same line except the backtrace, and then any additional properties are printed way down on the last line.I'd suggest instead printing a "list" of "maps", such that it'd look like
[{ function: "errors::new", file: "./src/new.rs", line: 21 }, ...]
.Allow passing the "precision" format flag to limit how many frames are printed. The most relevant frames are normally near the top, but deciding exactly how many depends on the app. Then a user could write
println!("short trace: {:.5}", trace)
to see just 5 frames.Remove
stack backtrace:\n
prefix entirely. When formatting, I'd think a user would pick their own prefix, likeprintln!("Call stack:\n{}", trace)
.The text was updated successfully, but these errors were encountered: