Repository navigation
Tracking Issue for Error in core #103765
Description
(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 forerror_generic_member_access#99301 - Final comment period (FCP)1
- Stabilization PR
Unresolved Questions
- None yet.
Footnotes
Reacted by Jacob Pratt, Robert Bamler, fintelia, Michał Borejszo, Philipp Schuster, Jakub Beránek, Raman Fedaseyeu, Vasiliy Kattouf, mseddon, Sam Estep and 31 more
Reacted by jyn, Alex Povel, Antonio, rmsyn, Aaron Kutch, Brad Gibson, Joshua Chapman and ver-nyan
Reacted by Dilshod Tadjibaev
Activity
lukas-code commentedon Oct 30, 2022
@rustbot label B-unstable A-error-handling
rustbot commentedon Oct 30, 2022
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.
Rollup merge of rust-lang#103766 - lukas-code:error-in-core, r=Dylan-DPC
robamler commentedon Dec 29, 2022
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_stdcompatible by default (without even requiring a cargo feature gate) were it not for their error types implementingstd::error::Error.yaahc commentedon Jan 19, 2023
@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
error_generic_member_access#99301This 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 commentedon Jan 21, 2023
@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 toerror_in_corewith your implementation in Move Error trait into core #99917, except that the methodcore::error::Error::providewould still be unstable with#![feature(error_generic_member_access)], just asstd::error::Error::provideis today; and#![feature(error_generic_member_access)]from stabilization; once those are resolved, bothstd::error::Error::provideandcore::error::Error::providewould 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 commentedon Jan 23, 2023
I think in theory we could stabilize error-in-core before provider but I'm worried since we removed
fn backtraceon the basis of the provider API, if we lock error into core we can never addfn backtraceback, and if we end up with some unavoidable blocker to stabilizing provider we may end up in a worse situation than we started.robamler commentedon Jan 28, 2023
I see, thanks! So I understand that maybe #99301 should be resolved first. I'm following up with the discussion there.
SimonIT commentedon Feb 9, 2023
yaahc commentedon Feb 10, 2023
Rollup merge of #103766 - lukas-code:error-in-core, r=Dylan-DPC
zdivelbiss commentedon Apr 1, 2023
Is there a FCP on the horizon for this feature? It seems relatively straight-forward insofar as its featureset, and it would be nice to allow thing like
anyhowto take advantage ofcore::error::Erroronstable.40 remaining items
io: always `impl Error for Errno` in rustc 1.81+
io: always `impl Error for Errno` in rustc 1.81+
io: always `impl Error for Errno` in rustc 1.81+
io: always `impl Error for Errno` in rustc 1.81+ (#1241)
mina-signer: make it no-std compatible
mina-signer: make it no-std compatible
mina-signer: make it no-std compatible
fix: make FromHexError work with no_std thiserror
fix: make FromHexError work with no_std thiserror
fix: make FromHexError work with no_std thiserror
feat(daemon): Phase 6 — adaptive TTL ladder + per-drive min_tier + sh…
feat(daemon): per-shard USN journal loops replace global 5-min tick (…
build: bump nightly to 2026-07-06 and migrate chunks_exact to as_chun…