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.
… rather than the module’s.
Remove code definition of the Error trait from its doc-comment
It was out of date, and rustdoc already shows the same information.
Add a default impl for Error::description and document it as deprecated.
It is redundant with Display while being much less flexible for implementors.
This is only a "soft" deprecation: it is not worth the hassle of a warning to existing users.
Tweak Error trait docs to reflect actual requirements
This commit is just covering the feature gate itself and the tests
that made direct use of `!` and thus need to opt back into the
feature.
A follow on commit brings back the other change that motivates the
revert: Namely, going back to the old rules for falling back to `()`.
Replace feature(never_type) with feature(exhaustive_patterns).
feature(exhaustive_patterns) only covers the pattern-exhaustives checks
that used to be covered by feature(never_type)
