This change hides the `anyhow` compatibility layer behind an `"anyhow"`
feature flag.
In `eyre` v1.0.0 the feature is currently enabled by default.
Fixes#131
---------
Co-authored-by: Freja Roberts <ten3roberts@gmail.com>
Prepares for a stable `1.0.0` release.
This release would signify the start of a stability commitment, and
allow us to update APIs to be reflictive or the current state and things
which we have learnt since.
@yaahc, I would like to request your signoff on this :)
The context chain downcast called converted to the wrong inner type
which caused the wrong drop impl to be called.
The tests did not catch this because they had compatible drop
implementations due to matching type layout. Solved by swizzling the
fields of the chain test types to force incompatible layouts
Resolves: #141
Previously, a closure and macro invocation was
required to generate a static string error object
from an `Option::None`.
This change adds an extension trait, providing
the `ok_or_eyre` method on the `Option` type.
`Option::ok_or_eyre` accepts static error messages
and creates `Report` objects lazily in the `None` case.
Implements #125
This change introduces the function eyre::Ok(), a backport of the convenience function anyhow::Ok() which avoids a lengthy turbofish when producing an Ok(()).
* Automatically convert to external errors
A pattern documented by thiserror is
```
pub enum MyError {
...
#[error(transparent)]
Other(#[from] anyhow::Error), // source and Display delegate to anyhow::Error
}
```
It'd be nice for this to work with ensure! but right now, that macro returns
an eyre error.
With this PR, the macro additionally runs an .into(). In the case that
the return type is an eyre error, obviously .into() will do nothing and
be compiled away. In the case that there is a from method, the wrapping
will occur. This enables eyre to be used for ergonomic 'implementation
detail error' in a thiserror using system which has contractual errors.
Since this conversion adds more flexibility to the result of these
macros, this could break code which relies on the narrowness to inform
type inference. If this is the case, update your code to specify the
result type you would like to use.
* Fix single-argument ensure test and allow dead code.
By adding the possibility for polymorphism from an eyre error, the
previous commit breaks a previous eyre test for single-argument
ensure!().
This change fixes that test and adds `allow(dead_code)` to the struct
used for the test for automatically converting to external errors.
---------
Co-authored-by: nori li <50680474+thenorili@users.noreply.github.com>
Adds documentation on the difference in performance characteristics between wrap_err vs wrap_err_with explored in Issue #126
---------
Co-authored-by: Jane Losare-Lusby <jlusby@yaah.dev>
RFC 2145 is in beta now, deprecating the public_in_private lint.
https://rust-lang.github.io/rfcs/2145-type-privacy.html
public_in_private has been superceded by three new lints. The first two
are warn-by-default and the third is allow-by-default. See the excerpt
below for some details.
This change skips this lint in nightly and beta in favor of the new
warn-by-default lints.
This change revealed a bug in the toolchain config option for
color-spantrace -- it doesn't exist! The lint it was guarding was never
turned on. This adds a minimal build script to check for toolchain to
color-spantrace. Its functionality is tested in the eyre crate, which
seems sufficient to me.
After this change there are only two more build warnings for eyre and
color-spantrace, the future-incompat dependency warning and the more
serious filename collision.
<quote>
Lint private_interfaces is reported when a type with visibility x is
used in primary interface of an item with effective visibility y and
x < y. This lint is warn-by-default.
Lint private_bounds is reported when a type or trait with visibility
x is used in secondary interface of an item with effective
visibility y and x < y. This lint is warn-by-default.
Lint unnameable_types is reported when effective visibility of a
type is larger than module in which it can be named, either
directly, or through reexports, or through trivial type aliases
(type X = Y;, no generics on both sides). This lint is
allow-by-default.
Compatibility lint private_in_public is never reported and removed.
</quote>
pyo3 v0.13.2 is tripping future-incompat. This change updates it to the newest 0.20.
pyo3 v0.16.0 renamed pvalue -> value.
The other future-incompat dependency, nom, is an indirect dependency through ansi-parser.
See issue 116
Warning: output filename collision appears in both stable and nightly builds.
It's slightly more impactful than just a warning. Running cargo +nightly
test, cargo test, cargo +nightly test in windows produces a linker error
where color-spantrace tries to use eyre's usage.exe, see error 2 below.
It's worked around pretty easily with cargo clean, but it's a problem
that might get worse as the monorepo effort expands!
This patch renames `usage.rs` to `CRATENAME-usage.rs`.
Issue #115
no_std support was removed in 2020 with PR #29. This change updates the documentation to reflect that as suggested in PR #89. It still mentions no_std, which will hopefully keep it on our minds enough to check sometimes and see if the upstream problem has been resolved.
Co-authored-by: Jane Losare-Lusby <jlusby@yaah.dev>
The rustdoc_missing_doc_code_examples lint has been sending
warnings and causing CI issues due to being an unstable feature.
This change introduces a small build script that detects whether
the current toolchain is nightly and, if so, sets the config option
"nightly_features". This config option then sets the feature gate
for missing_doc_code_examples and turns on 'warn'.
It expands the existing code for parsing minor version
to parse the rest of the rust --version.
This change also introduces a toolchain test that uses
rust_version to double-check that the config option was enabled
IFF the nightly toolchain is being used.
