Tracking issue for RFC 2504, "Fix the Error trait" #53487
Comments
Centril
added
B-RFC-approved
|
What parts haven't been implemented? |
|
I've updated the tracking issue to reflect that, but right now the |
|
Perhaps I could try implementing this, is it OK to just use the |
|
Implementing backtraces in the standard library will probably not use the The current platform-independent backtrace code lives here, mostly in the @laaas if you'd like to implement this please feel free! Also feel free to reach out with any questions. |
|
Thanks! Will definitely try implementing it. |
@laaas Did you make any progress? Need any help? |
|
@frewsxcv Actually not! I haven't really looked at it much, so if you want to work on it, go ahead! |
|
cc @rust-lang/libs @withoutboats @mitsuhiko would be really nice to make progress here |
|
I would move than love to spearhead this. |
|
@mitsuhiko go go go! if you need any help around the backtrace stuff @alexcrichton can get you set up. |
|
Just an update from my side about why there is no progress: I tried a few things to expose a sensible backtrace object and with the current system that is in place it's all too likely that the outcome is just a bad workaround. I'm currently leaning towards waiting for the backtrace support in rust to be based on backtrace-rs. |
|
Is migration to backtrace-rs is something that is already happening? Any issue to track progress? |
|
That landed ~4 days ago: #60852 |
|
Does this RFC also include backtrace printing for |
|
Has there been any discussion of supporting excluding the "runtime frames" similar to |
Improved backtrace support for errors in Rust is currently in progress: rust-lang/rust#53487. Adding the feature lets anyhow add backtraces already which greatly improves readability of errors in tests.
Starting in the most recent release of miri, the build.rs probe fails to
build even on nightly toolchain with one of the following errors:
error: miri can only run programs that have a main function
error: the current sysroot was built without `-Zalways-encode-mir`,
or libcore seems missing. Use `cargo miri setup` to prepare a
sysroot that is suitable for Miri.
which causes anyhow::Error's backtrace() inherent method to not exist.
error[E0658]: use of unstable library feature 'backtrace'
--> tests/test_backtrace.rs:20:19
|
20 | let _ = error.backtrace();
| ^^^^^^^^^
|
= note: see issue 53487 <rust-lang/rust#53487> for more information
= help: add `#![feature(backtrace)]` to the crate attributes to enable
|
The |
|
has this been given up on? |
|
It seems #77384 has been closed as "no longer necessary" but is still one of the tasks in the issue description above. There are other tasks such as "adjust documentation" which may be done already. I think this issue needs an update, and maybe can be closed. |
|
@yaahc I think this issue needs to be updated. Like the comments above say, this might be done. |
|
An overall update from the Error Handling Working Group would be nice. |
|
Yeah it would |
|
Hey, I'll do my best to give an update. First, the error handling project group has been inactive for quite a while. I think @rust-lang/libs probably needs to re-evaluate how they track subteams/subgroups and that as part of that, the error handling project group should either be officially shut down or rebooted. As for progress on the error trait, @waynr has started doing fantastic work finalizing the generic member access API. Reviewing the state of this tracking issue and #103765, I think this tracking issue may be superseded. There is the bit about formatting consistency that we may want to keep tracking in some issue and possibly some documentation related work but beyond that this issue seems essentially done. The next steps as I understand it are to polish and stabilize the generic member access API and eventually error in core. Disclaimer though, I've not been active in this area for a while now so I may be missing important details, if you see anything that I missed please point it out. |
|
How would we go around rebooting the error-handling project/group? |
* panicking will show the line number where the problem happens whereas otherwise we will get an error with no context at all * We anyhow capture the panics before returning to Go and thus, the process won't stop. Further context on why it's OK to use unwrap in these cases https://blog.burntsushi.net/unwrap/ Ideally we would have simply have a way to attach a backtrace/line-number to these errors instead, but I don't think that will be possible until rust-lang/rust#53487 is ready.
* panicking will show the line number where the problem happens whereas otherwise we will get an error with no context at all * We anyhow capture the panics before returning to Go and thus, the process won't stop. Further context on why it's OK to use unwrap in these cases https://blog.burntsushi.net/unwrap/ Ideally we would have simply have a way to attach a backtrace/line-number to these errors instead, but I don't think that will be possible until rust-lang/rust#53487 is ready.
* panicking will show the line number where the problem happens whereas otherwise we will get an error with no context at all * We anyhow capture the panics before returning to Go and thus, the process won't stop. Further context on why it's OK to use unwrap in these cases https://blog.burntsushi.net/unwrap/ Ideally we would have simply have a way to attach a backtrace/line-number to these errors instead, but I don't think that will be possible until rust-lang/rust#53487 is ready.
* panicking will show the line number where the problem happens whereas otherwise we will get an error with no context at all * We anyhow capture the panics before returning to Go and thus, the process won't stop. Further context on why it's OK to use unwrap in these cases https://blog.burntsushi.net/unwrap/ Ideally we would have simply have a way to attach a backtrace/line-number to these errors instead, but I don't think that will be possible until rust-lang/rust#53487 is ready.
|
Thanks for the update @yaahc , much appreciated.
Has this been formally brought up to the libs team? I think it would be interesting to have some public visibility (call for volunteers etc.) for efforts that are stalling out a bit (assuming lack of activity is the problem of course). |
ChrisDenton
added
the
I-libs-nominated
|
I've nominated this for discussion in a t-libs meeting for the reasons quoted above. |
|
Ah shoot, I forgot to respond to this issue when @yaahc pinged me last month. Yeah, I've been slowly making progress on the Error generic member access. One of my problems is that I am not very active in the Rust project to begin with and haven't been doing a very good job of attending to it consistently.
What does it mean to formally bring up stalled issues with the libs team? Ping in Zulip? Ping on tracking issues? Get a spot on their weekly meeting calendar?
While I have some consistency/time management problems and I am not exactly proficient with Rust at the level of others working on libs, I would like to get better in these areas and feel motivated to help out. So as far as volunteers go, I still want to do this! But eventually I won't have as much free time as I have had the past few months (currently unemployed, that could change as soon as the next few weeks) To avoid that scenario, I would definitely appreciate advice anyone has about how to procede (I realize that even though I may have ample free time to get things done, other people have more and different competing priorities so i may end up waiting longer than i would like for PR review). For example:
If there are higher priority items (like stabilizing @ChrisDenton is the libs team meeting open for anyone to attend? |
|
Hm, you may want to create a new topic on zulip if you need some advice on how to move forward. But yes, anyone can attend meetings. This is also organised on zulip. |
ChrisDenton
removed
the
I-libs-nominated
and others
This is a tracking issue for the RFC "Fix the Error trait" (rust-lang/rfcs#2504).
Steps:
sourcemethod Add Error::source method per RFC 2504. #53533backtracemodule #64154Implement proof of concept showing stabilizingbacktracemethod won't prevent movingErrorintocorelater Start working on proof of concept for exposing Backtrace in core #77384Precision flag support Formatting of std::backtrace::Backtrace #65280this is non-blocking for stabilizationpanic!backtraces Backtrace rendering inconsistent betweenstd::backtraceand panics #71706Unresolved questions:
Option<Backtrace>instead.Current status:
#53487 (comment)
The text was updated successfully, but these errors were encountered: