Repository: rust
Issue: Tracking Issue for `error::Report`
Labels: T-libs-api,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(error_reporter)]`

This is a tracking issue for a `Report` type that wraps an error, allowing the entire error chain to be printed in either single- or multi-line format. 

Implementation PR: https://github.com/rust-lang/rust/pull/91938

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
pub struct Report<E = Box<dyn Error>> {
    error: E,
    show_backtrace: bool,
    pretty: bool,
}

impl<E> Report<E>
where
    Report<E>: From<E>,
{
    pub fn new(error: E) -> Report<E>;
}

impl<E> Report<E> {
    pub fn pretty(mut self, pretty: bool) -> Self;
    pub fn show_backtrace(mut self, show_backtrace: bool) -> Self;
}

impl<E> From<E> for Report<E>
where
    E: Error;

impl<'a, E> From<E> for Report<Box<dyn Error + 'a>>
where
    E: Error + 'a;

impl<E> fmt::Display for Report<E>
where
    E: Error;

impl fmt::Display for Report<Box<dyn Error>>;

impl<E> fmt::Debug for Report<E>
where
    Report<E>: fmt::Display;

```

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- There exists an `impl<E> From<E> for Report<E> where E: Error` that converts an error into a report. Is it possible to make this work for types that convert into the inner error type?

Edit(yaahc):

- `show_backtrace` currently has no effect if the `pretty` format isn't enabled, we won't display backtraces ever in the single line format. I dislike this aspect, and am wondering if setting `show_backtrace` should implicitly also enable `pretty`, which isn't necessarily much better, but at least it's less error prone.
- I don't like the name of `pretty`, in the docs we refer to it as the multi-line format, should it just be `multiline`?
- I dislike how requiring the boolean for `pretty`/`show_backtrace` means you can't write something like `let val = my_result.map_err(Report::new).map_err(Report::pretty).unwrap();`, though I'm leaning towards this being the lesser evil compared to the issues with lifetimes and if statements on alternative builder API styles. It's not that big of a deal to introduce a closure like `.map_err(|r| r.pretty(should_be_pretty))`