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.

[jmillikin]

From reading this tracking issue and the two blocking tracking issues, it seems like feature(error_generic_member_access) continues to be an area of active development and iteration. Is there any way stabilization of core::error::Error could be decoupled from stabilization of the reflection-powered backtrace access?

There's a comment that removal of Error::backtrace() was predicated on existence of Provider (or equivalent), but I don't see why re-creating that API would be a blocker to stabilizing the rest of Error. Regardless of what the final backtrace-related access methods look like, they will have the following properties:

1. They'll need a default no-op implementation in the trait definition, which means that changing/adding/removing backtrace stuff in Nightly should not affect impl Error in Stable.
2. The types in core cannot reference OS-specific types or logic in std::backtrace, so the universe of possible method signatures added to core::error::Error is limited to those with some sort of indirection through an opaque type in core. If that type can't be referenced or constructed in Stable then it can't affect the API.

For example, various equivalent-but-alternate designs for stack trace access would be API-compatible with the stable parts of the core::error::Error API despite looking completely different in the unstable parts:

pub trait Error: Debug + Display {
    // stable
    fn source(&self) -> Option<&(dyn Error + 'static)> { ... }

    // stable + deprecated
    fn description(&self) -> &str { ... }
    fn cause(&self) -> Option<&dyn Error> { ... }

    // from the current definition of core::error::Error
    //
    // unstable, obvious and trivial default implementation, thus no API risk to Stable
    // even if the rest of `core::error::Error` is stabilized as-is.
    #[unstable]
    fn provide<'a>(&'a self, request: &mut Request<'a>) { }

    // returns an optional opaque handle to a separate #[unstable] metadata type,
    // sort of like the also-in-development DST metadata.
    //
    // changing to this approach from `provide()` would not affect stable API
    #[unstable]
    fn metadata<'a>(&'a self) -> Option<ErrorMetadata<'a>> { None }

    // another approach, where the `Error` implementation pokes things into
    // a provided opaque metadata structure. New methods and APIs could
    // be explored there without touching `Error` at all, stable or unstable.
    #[unstable]
    fn copy_metadata_to(&self, metadata: &mut dyn ErrorMetadata) { }
}