ohno: change Display implementation to show only top error message

[Vaiz]

ohno crate was designed with the idea that, by default, an error message should contain all the information you might need to understand what went wrong.

Right now it prints:

• its own message
• inner error message
• enrichment
• backtrace

this is not compatible with the way most other errors in the Rust ecosystem are implemented. In general, they only print their own top-level message. As a result, when ohno errors are combined with errors from other crates, the final displayed message ends up stopping at the first third‑party error.
A potential solution might be to align with common Rust practices: print only the top-level message in impl Display, and additionally provide a method (e.g. full) that preserves the current behavior

[martintmk]

The current Display impl in OhnoCore::format_error() (core.rs:135-153) dumps everything — message, enrichment entries, and backtrace — which breaks composability with the rest of the Rust ecosystem where Display shows only the top-level message.

A few additional observations:

1. The Provider API gap

Rust's std::error::Error::provide API (tracking issue #96024) would have been the natural way to attach structured metadata (enrichment entries, backtraces, labels) to errors without polluting Display. As of April 2026 it's still nightly-only and unstable. This means ohno currently has no standard mechanism to expose enrichment data other than baking it into the Display output — which is exactly what causes the composability problem described here.

2. A Report-style API — inspired by std::error::Report

There's already a tracking issue for a Report type in std: rust-lang/rust#90172 (feature gate error_reporter). It wraps any Error and provides both single-line and multi-line (pretty) output of the full error chain:

// std::error::Report API (nightly)
pub struct Report<E = Box<dyn Error>> {
    error: E,
    show_backtrace: bool,
    pretty: bool,
}

impl<E: Error> Report<E> {
    pub fn new(error: E) -> Report<E>;
    pub fn pretty(self, pretty: bool) -> Self;       // multi-line format
    pub fn show_backtrace(self, show_backtrace: bool) -> Self;
}

impl<E: Error> fmt::Display for Report<E>;  // renders the full chain

Usage:

// Single-line: "outermost error: second error: root cause"
eprintln!("{}", Report::new(&err));

// Multi-line with backtrace:
// outermost error
//
// Caused by:
//    0: second error
//    1: root cause
//
// Backtrace: ...
eprintln!("{}", Report::new(&err).pretty(true).show_backtrace(true));

This is still behind #![feature(error_reporter)] and unstable, but the design is solid and well-aligned with the eyre/anyhow ecosystem pattern:

• Display → top-level message only
• Report → full chain with causes, context, and backtrace

We should model our API after std::error::Report. ohno already has the building blocks — ErrorExt::message() returns just the main message (via format_message()), while Display returns everything. The fix would essentially be to swap these: make Display behave like today's message(), and introduce an explicit report type for full output.

3. The current Display/message duality is inverted

Right now:

Method	What it shows
Display ({})	message + enrichment + backtrace (full)
message()	message only (clean)

The Rust convention (and what std::error::Report reinforces) is:

Method	What it shows
Display ({})	message only (clean)
Report / Debug	full chain + context + backtrace

This inversion means any code doing format!("{err}") or err.to_string() with an ohno error gets a multi-line blob where other errors would give a one-liner. When ohno errors are chained with third-party errors via source(), the chain breaks at the first non-ohno error because those errors only print their own message in Display.

Suggested approach

1. Change Display to emit only the top-level message (what message() does today)
2. Add a Report wrapper type inspired by std::error::Report, with builder methods like .pretty(bool) and .show_backtrace(bool) that renders the full error chain, enrichment entries, and backtrace. Something like:

   // ohno::Report — inspired by std::error::Report
   let report = err.report();                    // single-line chain
   let report = err.report().pretty(true);       // multi-line with enrichment
   let report = err.report().show_backtrace(true); // include backtrace
   eprintln!("{report}");

3. Keep enrichment and backtrace accessible via enrichments(), backtrace(), and the new Report for callers who need the full picture
4. This would be a breaking change to Display output, so it should be coordinated as a semver bump

---

AI-generated reply by me giving it some research points and thinks to look for

[Vaiz]

suggested approach with report limits error details only to the top level error. afaik, there is no way to verify if underlying error types represented as Box<dyn Error> have report function that can be called to recursively to collect the full report from all errors in the chain.

I suggest you to experiment using this example as the basis: https://github.com/microsoft/oxidizer/blob/7f46a3f05c69baa900935e57352ff027999452e7/crates/ohno/examples/chained.rs

Ideally, we want report to preserve all enrichment from the whole chain.

---

Right now, there are a number of active RFC that can provide a better solution for this problem, but we need to wait for them to land.

List of RFCs that might help:

RFC 1210 - permits multiple impl blocks to apply to the same type/trait, so long as one of the blocks is clearly "more specific" than the other. The more specific impl block is used in a case of overlap.

RFC 3461 - Add functions for generic member access to dyn Error and the Error trait. There was an attempt to stabilize it, but it got postponed/canceled.

RFC 3885 - For any concrete type T, the set of #[exhaustive] traits it implements is finite and discoverable at runtime, enabling cross-trait casts.

try_as_dyn - try to turn any value into a dyn MyTrait. If the value does not implement MyTrait then we simply return None so that the user can have some default functionality happen instead.

[martin-kolinek]

Tracked internally as work item 7326955.