Implement Error for TryReserveError
I noticed that the Error trait wasn't implemented for TryReserveError. (#48043)
Not sure if the error messages and code style are 100% correct, it's my first time contributing to the Rust std.
`description` has been documented as soft-deprecated since 1.27.0 (17
months ago). There is no longer any reason to call it or implement it.
This commit:
- adds #[rustc_deprecated(since = "1.41.0")] to Error::description;
- moves description (and cause, which is also deprecated) below the
source and backtrace methods in the Error trait;
- reduces documentation of description and cause to take up much less
vertical real estate in rustdocs, while preserving the example that
shows how to render errors without needing to call description;
- removes the description function of all *currently unstable* Error
impls in the standard library;
- marks #[allow(deprecated)] the description function of all *stable*
Error impls in the standard library;
- replaces miscellaneous uses of description in example code and the
compiler.
Rename
* Error::iter_chain() -> Error::chain()
* ErrorIter -> Chain
Removed
* Error::iter_sources()
according to
https://github.com/rust-lang/rust/issues/58520
Rationale:
1. Such iterators are helpful. They should better be stabilized sooner
than later.
2. self should be included. It is easy to .skip(1) it.
Not including self is harmful because it is harder to add self
to the iterator than to remove it.
3. The chosen name should be telling and reflect the fact that self is
included. `.chain()` was chosen because the iterator iterates over
the chain of errors that is somehow included in self.
4. The resulting iterator is named `Chain` because the `error::Chain`
is what we want to have.
This commit adds a `backtrace` module to the standard library, as
designed in [RFC 2504]. The `Backtrace` type is intentionally very
conservative, effectively only allowing capturing it and printing it.
Additionally this commit also adds a `backtrace` method to the `Error`
trait which defaults to returning `None`, as specified in [RFC 2504].
More information about the design here can be found in [RFC 2504] and in
the [tracking issue].
Implementation-wise this is all based on the `backtrace` crate and very
closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise
it's pretty standard in how it handles everything internally.
[RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md
[tracking issue]: https://github.com/rust-lang/rust/issues/53487
cc #53487
error: remove StringError from Debug output
Seeing `StringError("something something")` in debug output can cause
someone to think there was an error dealing with `String`s, not that the
error type is just a string. So, remove that noise.
For example:
```
io error: Custom { kind: InvalidData, error: StringError("corrupt data") }
```
With this change:
```
io error: Custom { kind: InvalidData, error: "corrupt data" }
```
Fix intra-doc link resolution failure on re-exporting libstd
Currently, re-exporting libstd items as below will [occur a lot of failures](https://gist.github.com/taiki-e/e33e0e8631ef47f65a74a3b69f456366).
```rust
pub use std::*;
```
Until the underlying issue (#56922) fixed, we can fix that so they don't propagate to downstream crates.
Related: https://github.com/rust-lang/rust/pull/56941 (That PR fixed failures that occur when re-exporting from libcore to libstd.)
r? @QuietMisdreavus
type_id now takes an argument that can't be named outside of the
std::error module, which prevents any implementations from overriding
it. It's a pretty grody solution, and there's no way we can stabilize
the method with this API, but it avoids the soudness issue!
Closes#60784
Seeing `StringError("something something")` in debug output can cause
someone to think there was an error dealing with `String`s, not that the
error type is just a string. So, remove that noise.
This commit destabilizes the `Error::type_id` function in the standard library.
This does so by effectively reverting #58048, restoring the `#[unstable]`
attribute. The security mailing list has recently been notified of a
vulnerability relating to the stabilization of this function. First stabilized
in Rust 1.34.0, a stable function here allows users to implement a custom
return value for this function:
struct MyType;
impl Error for MyType {
fn type_id(&self) -> TypeId {
// Enable safe casting to `String` by accident.
TypeId::of::<String>()
}
}
This, when combined with the `Error::downcast` family of functions, allows
safely casting a type to any other type, clearly a memory safety issue! A
security announcement will be shortly posted to the security mailing list as
well as the Rust Blog, and when those links are available they'll be filled in
for this PR as well.
This commit simply destabilizes the `Error::type_id` which, although breaking
for users since Rust 1.34.0, is hoped to have little impact and has been deemed
sufficient to mitigate this issue for the stable channel. The long-term fate of
the `Error::type_id` API will be discussed at #60784.
Remove #[doc(hidden)] from Error::type_id
Nominating this for beta so that `Error::type_id` has documentation in time for release.
cc @rust-lang/release @rust-lang/docs
* Update bootstrap compiler
* Update version to 1.33.0
* Remove some `#[cfg(stage0)]` annotations
Actually updating the version number is blocked on updating Cargo
Add doc for impl From for Std Error
As part of issue #51430 (cc @skade).
I am not sure if it is going to a correct direction so put up here so that people can comment.
