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.

[robamler]

@yaahc Thank you for the references!

Do #![feature(error_in_core)] and #![feature(error_generic_member_access)] really have to be stabilized together? Maybe I'm missing something here, but it looks like the most pragmatic way forward would be to

1. first stabilize error_in_core with your implementation in Move Error trait into core #99917, except that the method core::error::Error::provide would still be unstable with #![feature(error_generic_member_access)], just as std::error::Error::provide is today; and
2. then resolve any issues that are blocking #![feature(error_generic_member_access)] from stabilization; once those are resolved, both std::error::Error::provide and core::error::Error::provide would become available on stable.

(I'll reach out on zulip if I don't get any response here; just wanted to leave this comment here as a kind of documentation in case I can't figure this out and someone else needs to take over.)

[yaahc]

I think in theory we could stabilize error-in-core before provider but I'm worried since we removed fn backtrace on the basis of the provider API, if we lock error into core we can never add fn backtrace back, and if we end up with some unavoidable blocker to stabilizing provider we may end up in a worse situation than we started.

[robamler]

I see, thanks! So I understand that maybe #99301 should be resolved first. I'm following up with the discussion there.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[wmmc88]

Is this targeted for release for 1.81.0? I see no mention of it in https://releases.rs/docs/1.81.0/

[faern]

Is this targeted for release for 1.81.0? I see no mention of it in https://releases.rs/docs/1.81.0/

It is. You can see in the docs for the beta that the core::error module is stable. Compare with docs for stable.

[m4rch3n1ng]

I see no mention of it in https://releases.rs/docs/1.81.0/

it doesn't show up on releases.rs, because the stabiliziation pr #125951 is not marked with the relnotes label