| Age | Commit message (Collapse) | Author | Lines |
|
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
|
|
|
|
|
|
|
|
|
|
Stabilize TryFrom and TryInto with a convert::Infallible empty enum
This is the plan proposed in https://github.com/rust-lang/rust/issues/33417#issuecomment-423073898
|
|
|
|
|
|
impl iter() for dyn Error
Examples:
```rust
let next_error_type_a = err
.iter()
.filter_map(Error::downcast_ref::<ErrorTypeA>)
.next();
```
```rust
let source_root_error = err.iter().last();
```
Credit for the ErrorIter goes to reddit user /u/tdiekmann (Tim Diekmann)
https://www.reddit.com/r/rust/comments/aj3lpg/is_an_iterator_impl_over_errorsource_possible/
|
|
|
|
Examples:
```rust
let next_error_type_a = err
.iter_chain()
.filter_map(Error::downcast_ref::<ErrorTypeA>)
.next();
```
```rust
let source_root_error = err.iter_chain().last();
```
Credit for the ErrorIter goes to Tim Diekmann
https://www.reddit.com/r/rust/comments/aj3lpg/is_an_iterator_impl_over_errorsource_possible/
|
|
This should have been part of https://github.com/rust-lang/rust/pull/57834
FCP: https://github.com/rust-lang/rust/issues/27745#issuecomment-373906749
|
|
of `cause`
|
|
|
|
* Update bootstrap compiler
* Update version to 1.33.0
* Remove some `#[cfg(stage0)]` annotations
Actually updating the version number is blocked on updating Cargo
|
|
|
|
r=GuillaumeGomez
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The heap.rs file was already unused.
|
|
|
|
… 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 reverts commit e53a2a72743810e05f58c61c9d8a4c89b712ad2e.
|
|
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 `()`.
|
|
|
|
|
|
… to make the name `alloc` available.
|
|
Tracking issue: https://github.com/rust-lang/rust/issues/33417
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
|
Add blanket TryFrom impl when From is implemented.
Adds `impl<T, U> TryFrom<T> for U where U: From<T>`.
Removes `impl<'a, T> TryFrom<&'a str> for T where T: FromStr` (originally added in #40281) due to overlapping impls caused by the new blanket impl. This removal is to be discussed further on the tracking issue for TryFrom.
Refs #33417.
/cc @sfackler, @scottmcm (thank you for the help!), and @aturon
|
|
|
|
|
|
|
|
|
|
|
|
These show up in rustdoc so need to be correct.
|
|
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/197
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
|
|
add `FromStr` Impl for `char`
fixes #24939.
is it possible to use pub(restricted) instead of using a stability attribute for the internal error representation? is it needed at all?
|