-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement core::error::Error
#630
Conversation
see #629 for an alternative approach which however doesn't seem to work (but would be much more concise if it did!) |
c99eb75
to
91cf7e1
Compare
this trait has been stabilised in Rust 1.81.0. the existing custom `Error` types cannot be removed / replaced as that'd be a breaking change. for the same reason it's not possible for them to require `core::error::Error` being implemented. however, we can already implement the new trait for all cases where the custom trait has been implemented so far. existing `std` feature-gated implementations of `std::error::Error` have also been moved to `core::error::Error` and the feature gate removed. this raises the MSRV to 1.81.0 for most crates, but based on the MSRV policy this should not be an issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, this is the most reasonable way of adding core::error::Error
(the other PR with dyn
is a bit weird)
the other concern is when to merge and when to release, since this is quite a big msrv bump. I don't have opinions, would be ok with both doing it now or waiting. Will leave to other hal team members to decide.
Looks good. Is there an example on how that would be used in practice (in a hal impl and then in e.g. a device driver)? I would now expect device drivers to The full solution appears to be |
How does the error trait fit with defmt? Is it possible to use it properly while still leveraging the greatness of defmt? |
This doesn't take away anything. It only adds the trait. You don't need to use it, so there's nothing getting in the way of defmt |
Yeah, I get that. The question was more on whether there is a way to utilize the error trait in a defmt application, or if that would always end up being all device side formatting? |
2 weeks have passed and no one from the HAL team has raised concerns, let's merge. I propose merging but waiting a bit more for release. |
this trait has been stabilised in Rust 1.81.0.
the existing custom
Error
types cannot be removed / replaced as that'd be a breaking change. for the same reason it's not possible for them to requirecore::error::Error
being implemented.however, we can already implement the new trait for all cases where the custom trait has been implemented so far.
existing
std
feature-gated implementations ofstd::error::Error
have also been moved tocore::error::Error
and the feature gate removed.this raises the MSRV to 1.81.0 for most crates, but based on the MSRV policy this should not be an issue.