Tracking Issue for `Error` in `core`

[lukas-code]

(This was merged a while ago without a tracking issue, so I'm creating this one here now.)

Feature gate: #![feature(error_in_core)]

This is a tracking issue for moving the Error trait to the core library.

Public API

// core::error
pub trait Error: Debug + Display  {
    /* same API as std::error::Error */
}

// unstable in core, stable in std
impl dyn Error + 'static [+ Send [+ Sync]] {
    pub fn is<T: Error + 'static>(&self) -> bool;
    pub fn downcast_ref<T: Error + 'static>(&self) -> Option<&T>;
    pub fn downcast_mut<T: Error + 'static>(&mut self) -> Option<&mut T>;
}

// unstable in alloc, stable in std
impl dyn Error [+ Send [+ Sync]] {
    pub fn downcast<T: Error + 'static>(self: Box<Self>) -> Result<Box<T>, Box<Self>>;
}

Steps / History

• Implementation (first attempt, closed): Move the Error trait into core (without fn backtrace) #90328
• Implementation (merged): Move Error trait into core #99917
• Stabilize the Provider API: Tracking Issue for Provider API #96024
• Stabilize error_generic_member_access: Tracking Issue for error_generic_member_access #99301
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[lukas-code]

@rustbot label B-unstable A-error-handling

[rustbot]

Error: Label B-unstable can only be set by Rust team members

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[robamler]

I'm excited about this feature, so if there's anything I can do to help pushing it over the finish line I'd be happy to help. I'm fairly experienced with programming in Rust and I've been silently following various Rust features from RFC to stabilization, but I haven't myself contributed to the compiler or standard library yet.

I think this feature could turn out to be a considerable improvement to Rust. There are quite a few small-ish crates out there that only perform well-specified pure-function-like operations. I can imagine that many of these crates could trivially be no_std compatible by default (without even requiring a cargo feature gate) were it not for their error types implementing std::error::Error.

[yaahc]

@robamler that would be lovely, I'm happy to hand off and help coordinate that work. I've been focused on governance work since august and haven't had much time for pushing this across the finish line.

I believe the current blockers for this are resolving issues in the provider / generic member access APIs

• Tracking Issue for Provider API #96024
• Tracking Issue for error_generic_member_access #99301

This comment by @dtolnay best outlines the issues that still need to be resolved: #99301 (comment)

Let me know if you have any further questions. The zulip is probably the best way to reach me quickly. I'm not keeping on top of github notifications right now since I still need to unsubscribe to a bunch of things to turn down the volume of notifications I get daily.