The lint group is `clippy::suspicious`, not `clippy::suspiscious`
https://github.com/eyre-rs/eyre/actions/runs/9112483886/job/25051828362#step:5:176
```
warning[E0602]: unknown lint: `clippy::suspiscious`
Warning: |
= help: did you mean: `clippy::suspicious`
= note: requested on the command line with `-D clippy::suspiscious`
= note: `#[warn(unknown_lints)]` on by default
```
Deny style, suspicious and complexity categories, rather than all
warnings
If we find issues that could have been caught by a clippy lint we can
add that lint on as *deny* too, as for now, they still appear as
warnings but won't prevent CI from running.
This most notably fixes random CI breakages when clippy/rust updates and
introduces new warn level lints
Fixes#169
Besides enclosing inline code in backticks, I also made two tiny
documentation improvements - please let me know if you want them undone:
- In the `Report::msg` docs, the user is referred to `Report::new`. I
changed this from plain inline code into a link.
- I expanded _"`Display` impl"_ to _"`Display` implementation"_, since
`impl` is a Rust token, but
- _"`Display` `impl`"_ looked silly, and
- _"`impl Display`"_ disturbed the flow of reading.
Co-authored-by: Jane Losare-Lusby <jlusby@yaah.dev>
Since almost all files not on our gitignore are text files, it uses `*
text` as a catch-all and specifies *.png as binary.
Co-authored-by: Jane Losare-Lusby <jlusby@yaah.dev>
Applies the same fixes that was applied to `color-eyre-0.6` to master,
namely the new update to `trybuild` that breaks our MSRV requirement,
requiring us to pin the version, as the dependency only bumped the patch
version for the updated MRSV.
It also fixes the theme test breaking on windows due to new
*before-main* machinery on windows affecting the backtrace. This is
fixed by filtering out the functions before and including main(due to no
take_until iter adapter in std), but still includes the panicking
function call.
There are currently three branches that need/needed this fix
- master: containing latest breaking code for 1.0
- color-eyre-0.6
- release-0.6 (does not include the theme test change as color-eyre is
not present there)
1. Remove the conditional trait methods `context` and `with_context`
from `WrapErr`
2. Remove ambiguity between "wrapping errors" with another, and
converting a `None` value to an error.
The anyhow compatibility methods (`context` and `with_context`) were
introduced as conditional required methods for the trait `WrapErr`, as
well as another separate trait `ContextCompat`, implemented for options
*and* results.
The latter trait also provided methods `wrap_err` and `wrap_err_with`.
This led to confusion as the two distinct traits had the same methods,
one was implemented on results, and the other on both options and
results.
Furthermore, wrapping options does not align with our error model where
errors are wrapped around other errors; an error wrapping `None` should
just be a single error and should not be wrapped.
See: #149
# 1. Clarify trait usage in location test
[`8522f02`](8522f02518)
Both `WrapErr` and `ContextCompat` expose `anyhow` compatibility
methods.
- `ContextCompat` is completely feature gated behind the `anyhow` flag.
- `WrapErr`, on the other hand, feature-gates individual functions
behind the `anyhow` flag.
This has led to [confusion][confusion] in the past.
This change moves the `use eyre::WrapErr` statement from the top of the
module into each individual test, as [identically named
functions](https://github.com/eyre-rs/eyre/issues/149) (`wrap_err.*`)
are exposed both by `WrapErr` and `ContextCompat`.
With `use eyre::WrapErr` moved directly into the tests, it becomes clear
which trait-provided `fn` is being called.
[confusion]:
https://github.com/eyre-rs/eyre/pull/138#discussion_r1432909562
# 2. Remove `anyhow` feature flag from `OptionExt` location test
[`68744f1`](68744f19fb)
This bug was introduced (by me) in
34bd1d9893 (diff-1ff47dac6cf55e34ff587968c5b1f1ec6b6ae39d2668a66ecba3633163a21fc5R86)
- partly due to the confusion fixed with the above commit.
Fixes https://github.com/eyre-rs/eyre/issues/147
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>
