Skip to content
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

Filter stdlib out of stack traces #25621

Closed
jimmycuadra opened this issue May 19, 2015 · 2 comments
Closed

Filter stdlib out of stack traces #25621

jimmycuadra opened this issue May 19, 2015 · 2 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jimmycuadra
Copy link
Contributor

Stack traces would be much easier to digest if the lines from stdlib were removed before being printed to the user. For example, take this output from calling option.unwrap on a None value in a test from a project I'm working on:

---- compare_and_delete stdout ----
    thread 'compare_and_delete' panicked at 'called `Option::unwrap()` on a `None` value', /home/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/option.rs:362

stack backtrace:
   1:     0x7f12357e3689 - sys::backtrace::write::hbc46dc0cfb3b9537d4r
   2:     0x7f12357e6c46 - panicking::on_panic::h74d3c14d86c58ac8jrw
   3:     0x7f12357d8a92 - rt::unwind::begin_unwind_inner::h382cea404b11eb00t6v
   4:     0x7f12357d94ec - rt::unwind::begin_unwind_fmt::h5c14cfc30901d9d274v
   5:     0x7f12357e68d6 - rust_begin_unwind
   6:     0x7f1235814184 - panicking::panic_fmt::h9ea3571c30b632b3wwy
   7:     0x7f1235814104 - panicking::panic::h0265a6efa68361e53uy
   8:     0x7f1235660991 - option::Option<T>::unwrap::h8561976572633329008
                        at /home/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/macros.rs:19
   9:     0x7f12356612c4 - compare_and_delete::h6f5ab680c2a34c3feia
                        at tests/client_test.rs:62
  10:     0x7f123575e39b - boxed::F.FnBox<A>::call_box::h15853468894108720310
  11:     0x7f123576190b - boxed::F.FnBox<A>::call_box::h15343356339842678509
  12:     0x7f123575eb59 - rt::unwind::try::try_fn::h11678192874774444076
  13:     0x7f12357eb6a8 - rust_try_inner
  14:     0x7f12357eb695 - rust_try
  15:     0x7f123575ee08 - boxed::F.FnBox<A>::call_box::h13152174250445044076
  16:     0x7f12357e5c21 - sys::thread::create::thread_start::h490278b5c3c0b49faqv
  17:     0x7f12340ed0a3 - start_thread
  18:     0x7f12348ed04c - clone
  19:                0x0 - <unknown>

While it may be accurate, what I want as a programmer is to know what part of my code caused the exception. The error message only tells me about the implementation of the Option type, and I have to dig through a stack trace of stuff from the stdlib to find the line that tells me it came from tests/client_test.rs:62 in my code.

I talked with @wycats about this briefly at the Rust 1.0 launch party and he agreed that we probably need something akin to ActiveSupport::BacktraceCleaner from Rails.

This might actually be two issues – one is that the error message should show the line in my code where the unwrap happened, not the line in option.rs where the panic was actually triggered, and the other is the filtering of lines in the stack trace. Let me know if I should split part of this off into a separate issue.

@Aatch Aatch added the A-diagnostics Area: Messages for errors, warnings, and lints label May 20, 2015
@steveklabnik
Copy link
Member

Triage: no change

@steveklabnik steveklabnik added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 9, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 22, 2017
@estebank
Copy link
Contributor

#38165 implemented a fairly thorough pruning of the backtrace by default, which solves this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants