Jane Losare-Lusby comments

Results 180 comments of


                                            Jane Losare-Lusby

Proof of concept of dyn dispatch based report handler

> Separately, from skimming crates.io it looks like the majority of the downstream crates not written by you are using old versions of eyre i.e. without this implementation; ideally we'd...

Proof of concept of dyn dispatch based report handler

https://github.com/yaahc/color-anyhow/actions/runs/174054634 seems to be working ^_^ Edit: JK, it doesn't work for the `fn backtrace` on nightly, as I feared. It looks like the `cfg(backtrace)` doesn't transitively apply to `color-anyhow`...

Proof of concept of dyn dispatch based report handler

I've run into another snag with implenting backtrace support in `color-anyhow`. by default `color-anyhow` always captures a backtrace, even on stable via `backtrace-rs`, where it then uses the frame api...

Proof of concept of dyn dispatch based report handler

Well, with sufficient application of `build.rs` files I got it all working, I now have a full version of `color-eyre` working ontop of anyhow that even uses `std::backtrace::Backtrace` on nightly...

Proof of concept of dyn dispatch based report handler

@mystor raised some pretty good concerns about the `#[cfg(backtrace)]` public trait fn and requiring implementors of `ReportHandler` to vendor the `build.rs` logic to correctly implement the trait being fragile and...

Proof of concept of dyn dispatch based report handler

Regarding the earlier question about how "Baked" the design is. One area where I don't think its fully baked yet is how it interacts with `#[track_caller]`. I recently tried using...

Proof of concept of dyn dispatch based report handler

## Status update I've had `track_caller` in `eyre` for a while now, been working great no issues there, and a breaking change was not necessary. Other than that for a...

Proof of concept of dyn dispatch based report handler

> @yaahc @dtolnay What's the status on this PR? There’s a bit of an ecosystem split between `anyhow` and `eyre` and this seems like a great way to help unify...

RFC: Add support for customizable error handlers based on `eyre`

One possible solution for the fn Backtrace stuff would be to wrap the inner error in a newtype that transparently forwards `Display` and `Debug` to the inner error but yields...

Bug: `color_eyre` interference with `tracing` in some cases

wow, that's uuuh, interesting... I'll look into what's causing that. For now is installing the subscriber first possible? I'm just trying to get a sense of this issue's urgency.