-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 error interoperation #17747
Comments
As per [RFC 70](https://github.com/rust-lang/rfcs/blob/master/active/0070-error-chaining.md) Closes rust-lang#17747 Note that the `error` module must live in `std` in order to refer to `String`. Note that, until multidispatch lands, the `FromError` trait cannot be usefully implemented outside of the blanket impl given here.
This PR: * Adds the error interoperation traits (`Error` and `FromError`) to a new module, `std::error`, as per [RFC 70](https://github.com/rust-lang/rfcs/blob/master/active/0070-error-chaining.md). Note that this module must live in `std` in order to refer to `String`. Note that, until multidispatch lands, the `FromError` trait cannot be usefully implemented outside of the blanket impl given here. * Incorporates `std::error::FromError` into the `try!` macro. * Implements `Error` for most existing error enumerations. Closes #17747
As per [RFC 70](https://github.com/rust-lang/rfcs/blob/master/active/0070-error-chaining.md) Closes rust-lang#17747 Note that the `error` module must live in `std` in order to refer to `String`. Note that, until multidispatch lands, the `FromError` trait cannot be usefully implemented outside of the blanket impl given here.
This PR: * Adds the error interoperation traits (`Error` and `FromError`) to a new module, `std::error`, as per [RFC 70](https://github.com/rust-lang/rfcs/blob/master/active/0070-error-chaining.md). Note that this module must live in `std` in order to refer to `String`. Note that, until multidispatch lands, the `FromError` trait cannot be usefully implemented outside of the blanket impl given here. * Incorporates `std::error::FromError` into the `try!` macro. * Implements `Error` for most existing error enumerations. Closes #17747
As per [RFC 70](https://github.com/rust-lang/rfcs/blob/master/active/0070-error-chaining.md) Closes rust-lang#17747 Note that the `error` module must live in `std` in order to refer to `String`. Note that, until multidispatch lands, the `FromError` trait cannot be usefully implemented outside of the blanket impl given here.
This PR: * Adds the error interoperation traits (`Error` and `FromError`) to a new module, `std::error`, as per [RFC 70](https://github.com/rust-lang/rfcs/blob/master/active/0070-error-chaining.md). Note that this module must live in `std` in order to refer to `String`. Note that, until multidispatch lands, the `FromError` trait cannot be usefully implemented outside of the blanket impl given here. * Incorporates `std::error::FromError` into the `try!` macro. * Implements `Error` for most existing error enumerations. Closes #17747
In the error chaining RFC the return type of |
@michaelsproul The reason the API was changed was to support another pattern: that you lazily perform the allocation and creation of the string, based on more meaningful fields that are part of the error type. But that does mean you have to create a fresh copy each time. It just occurred to me that the best solution might instead be to use the |
fix: Errors on method call inferences with elided lifetimes Fixes rust-lang#17734 Currently, we are matching non-lifetime(type or const) generic arg to liftime argument position while building substs for method calling when there are elided lifetimes. This mismatch just make a subst for error lifetime and while this alone is not much a trouble, it also makes the mismatched type or const generic arg cannot be used in its proper place and this makes type inference failure
Tracking issue for rust-lang/rfcs#201
I'm not nominating this because this is a library issue, which is handled with stabilization rather than nomination.
The text was updated successfully, but these errors were encountered: