Repository navigation
Tracking issue for RFC 2504, "Fix the Error trait" #53487
Description
This is a tracking issue for the RFC "Fix the Error trait" (rust-lang/rfcs#2504).
Steps:
- Implement the RFC (cc @rust-lang/libs)
-
sourcemethod Add Error::source method per RFC 2504. #53533 - Backtrace API std: Add a
backtracemodule #64154
-
-
Implement proof of concept showing stabilizingbacktracemethod won't prevent movingErrorintocorelater Start working on proof of concept for exposing Backtrace in core #77384 - Fix std::backtrace::Backtrace's fmt representations
Precision flag support Formatting of std::backtrace::Backtrace #65280this is non-blocking for stabilization- Differences with
panic!backtraces Backtrace rendering inconsistent betweenstd::backtraceand panics #71706
- Adjust documentation (see instructions on forge)
- Stabilization PR (see instructions on forge)
Unresolved questions:
- The choice to implement nullability internal to backtrace may prove to be a mistake: during the period when backtrace APIs are only available on nightly, we will gain more experience and possible change backtrace's constructors to return an
Option<Backtrace>instead.
Current status:
Metadata
Metadata
Assignees
Labels
Area: Error handlingBlocker: Approved by a merged RFC but not yet implemented.Category: An issue tracking the progress of sth. like the implementation of an RFCLibs issues that are tracked on the team's radar.Project group: Error handling (https://github.com/rust-lang/project-error-handling)Relevant to the library team, which will review and decide on the PR/issue.
Activity
L-as commentedon Sep 26, 2018
What parts haven't been implemented?
withoutboats commentedon Sep 26, 2018
I've updated the tracking issue to reflect that, but right now the
sourcemethod has been implemented, but the backtrace related APIs have not been implementedL-as commentedon Sep 26, 2018
Perhaps I could try implementing this, is it OK to just use the
backtracecrate?alexcrichton commentedon Oct 2, 2018
Implementing backtraces in the standard library will probably not use the
backtracecrate but rather the backtrace API that's already in the standard library forRUST_BACKTRACE. We can perhaps unify these implementations in the long run, but for now it's infeasible to do so.The current platform-independent backtrace code lives here, mostly in the
_printfunction. Implementing the API defined in the RFC will likely involve reusing these interfaces to define a struct which carries along the relevant information.@laaas if you'd like to implement this please feel free! Also feel free to reach out with any questions.
L-as commentedon Oct 2, 2018
Thanks! Will definitely try implementing it.
frewsxcv commentedon Nov 22, 2018
@laaas Did you make any progress? Need any help?
L-as commentedon Nov 22, 2018
@frewsxcv Actually not!
I haven't really looked at it much, so if you want to work on it, go ahead!
aturon commentedon Feb 21, 2019
cc @rust-lang/libs @withoutboats @mitsuhiko would be really nice to make progress here
mitsuhiko commentedon Feb 22, 2019
I would move than love to spearhead this.
aturon commentedon Feb 22, 2019
@mitsuhiko go go go! if you need any help around the backtrace stuff @alexcrichton can get you set up.
mitsuhiko commentedon May 26, 2019
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.
idubrov commentedon May 30, 2019
Is migration to backtrace-rs is something that is already happening? Any issue to track progress?
131 remaining items
nyabinary commentedon Jul 25, 2023
Yeah it would
yaahc commentedon Jul 25, 2023
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.
nyabinary commentedon Jul 25, 2023
How would we go around rebooting the error-handling project/group?
Use unwrap() in errors due to bugs in the Go<->Rust interface
Use unwrap() in errors due to bugs in the Go<->Rust interface
Use unwrap() in errors due to bugs in the Go<->Rust interface
Use unwrap() in errors due to bugs in the Go<->Rust interface (#879)
dralley commentedon Aug 24, 2023
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 commentedon Aug 24, 2023
I've nominated this for discussion in a t-libs meeting for the reasons quoted above.
waynr commentedon Aug 24, 2023
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:
error_generic_member_access#99301 by now)error_generic_member_access#99301 - needs the Steps/History list in the description updatedIf there are higher priority items (like stabilizing
error_in_core) I'd be happy to take a look at those in addition toerror_generic_member_access.@ChrisDenton is the libs team meeting open for anyone to attend?
ChrisDenton commentedon Aug 24, 2023
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.