-
Notifications
You must be signed in to change notification settings - Fork 102
Fix compile probe and nightly backtraces #160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 3 commits
f80de3e
92b6a57
3d7b20d
dacfb55
dd05aa3
87ee15e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -122,9 +122,12 @@ avoid using `eyre::Report` as your public error type. | |
| } | ||
| ``` | ||
|
|
||
| - If using the nightly channel, a backtrace is captured and printed with the | ||
| error if the underlying error type does not already provide its own. In order | ||
| to see backtraces, they must be enabled through the environment variables | ||
| - If using rust >1.65, a backtrace is captured and printed with the | ||
| error. | ||
|
|
||
| On nightly eyre will use the underlying error's backtrace if it has one. | ||
|
|
||
| In order to see backtraces, they must be enabled through the environment variables | ||
| described in [`std::backtrace`]: | ||
|
|
||
| - If you want panics and errors to both have backtraces, set | ||
|
|
@@ -141,7 +144,7 @@ avoid using `eyre::Report` as your public error type. | |
| - Eyre works with any error type that has an impl of `std::error::Error`, | ||
| including ones defined in your crate. We do not bundle a `derive(Error)` macro | ||
| but you can write the impls yourself or use a standalone macro like | ||
| [thiserror]. | ||
| [thiserror](https://github.com/dtolnay/thiserror). | ||
|
|
||
| ```rust | ||
| use thiserror::Error; | ||
|
|
@@ -178,6 +181,15 @@ No-std support was removed in 2020 in [commit 608a16a] due to unaddressed upstre | |
| [commit 608a16a]: | ||
| https://github.com/eyre-rs/eyre/pull/29/commits/608a16aa2c2c27eca6c88001cc94c6973c18f1d5 | ||
|
|
||
|
|
||
| ## Backtrace support | ||
|
|
||
| The built in default handler has support for capturing backtrace using `rustc-1.65` or later. | ||
|
|
||
| Backtraces are captured when an error is converted to an `eyre::Report` (such as using `?` or `eyre!`). | ||
|
|
||
| If using the nightly toolchain, backtraces will also be captured and accessed from other errors using [error_generic_member_access](https://github.com/rust-lang/rfcs/pull/2895) if available. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Per #121, some folks will continue to be unhappy about enforcing unstable features whenever we detect nightly. IIRC we discussed a while ago that we want to accomodate that use case. It doesn't make it any worse so I think it's fine to put that work off, but I thought it was worth mentioning.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, not wanting to break existing behavior in a "fix" PR, but rather make existing up to date nightly a tricky beast when it comes to libraries. |
||
|
|
||
| ## Comparison to failure | ||
|
|
||
| The `eyre::Report` type works something like `failure::Error`, but unlike | ||
|
|
@@ -195,8 +207,6 @@ you need an error type that can be handled via match or reported. This is | |
| common in library crates where you don't know how your users will handle | ||
| your errors. | ||
|
|
||
| [thiserror]: https://github.com/dtolnay/thiserror | ||
|
|
||
| ## Compatibility with `anyhow` | ||
|
|
||
| This crate does its best to be usable as a drop in replacement of `anyhow` and | ||
|
|
||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What was your motivation for rewriting this file? |
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not your code / out of scope: We're getting a couple dead code errors in this file with DisplayError and NoneError. I'm surprised they're triggered even though we marked them public. Why don't we tag these structs as I am similarly distressed by the other warnings we get a dozen copies of down below. I thought the missing_doc_code_examples thing was resolved ages ago. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I understand that. I guess my surprise is that it's existing code that's had attention paid to its visibility and yet it's dead. I'll find the last time it wasn't dead code and figure its story out. |
Uh oh!
There was an error while loading. Please reload this page.