This adds a default type parameter to the `T` value of `eyre::Result`.
```rust
pub type Result<T = (), E = Report> = core::result::Result<T, E>;
```
Because `Result<()>` is so incredibly common, allow users to just write
`-> Result {` instead of `-> Result<()>`
Considering that the default function return type is `()` which you
don't have to specify, I think it's appropriate to do that here, as
well.
This is particularly high-impact for:
- Tests
- the `main` function
- Functions that only do IO, without returning any other value
All use-cases where `eyre` particularly shines.
You can now write:
```rust
#[test]
fn test() -> Result {
```
And:
```rust
fn main() -> Result {
```
There are 2.2 million cases where `Result<()>` is used, and this change
will have quite a lot of impact, as github search shows:
https://github.com/search?q=path%3A*.rs%20%2FResult%3C%5C(%5C)%3E%2F&type=code
I don't think `eyre` should be offering integrations with specific
crates' error types. `anyhow` makes sense since it is an error handling
library, but `pyo3` does not: `pyo3` should instead offer that
integration as a feature. This is a common pattern in the ecosystem:
`serde` doesn't depend on other projects.
A reason `pyo3` is particularly problematic is that it has a build
script that checks Python versions: this means `eyre` cannot be built
with `--all-features` (done by a lot of tooling like cargo
semver-checks) on systems without the exact expected Python version.
If we're doing a 1.0, we should remove this feature. We can add it back
if it turns out that pyo3 can't add an eyre dep.
Considering eyre plans to do a 1.0 release soon
(https://github.com/eyre-rs/eyre/pull/269), it's a good time to clean up
the API
I think the `WrapErr` trait should be renamed to `ResultExt`
For one, the names of these 2 traits `WrapErr` and `OptionExt` are
inconsistent.
The `WrapErr` trait is only implemented for `Result`. There are no other
types with `.wrap_err` operations. The trait is sealed. It's an
extension trait. As such, I think it's best to rename it to be more
inline with extension trait naming conventions.
It is an [established
convention](26197104b7/text/0445-extension-trait-conventions.md)
of using "Ext" as part of an extension trait name.
Examples in std:
-
[`std::os::unix::fs::FileExt`](https://doc.rust-lang.org/nightly/std/os/unix/fs/trait.FileExt.html)
-
[`std::os::windows::fs::FileExt`](https://doc.rust-lang.org/nightly/std/os/windows/fs/trait.FileExt.html)
-
[`std::ascii::AsciiExt`](https://doc.rust-lang.org/nightly/std/ascii/trait.AsciiExt.html)
-
[`std::os::unix::ffi::OsStrExt`](https://doc.rust-lang.org/nightly/std/os/unix/ffi/trait.OsStrExt.html)
-
[`std::os::windows::ffi::OsStrExt`](https://doc.rust-lang.org/nightly/std/os/windows/ffi/trait.OsStrExt.html)
This actually improves clarity of the documentation. See these docs:
```rust
//! ### `Context` and `Option`
//!
//! As part of renaming `Context` to `ResultExt` we also intentionally do not
//! implement `ResultExt` for `Option`. This decision was made because `wrap_err`
//! implies that you're creating a new error that saves the old error as its
//! `source`. With `Option` there is no source error to wrap, so `wrap_err` ends up
//! being somewhat meaningless.
```
Considering that the trait is now called `ResultExt`, the fact that it
is not implemented for `Option` naturally stems from the fact that it is
called `ResultExt`. So it doesn't warrant a special case to be explained
in the documentation.
We can of course adjust the documentation after this PR.
- **chore: Update checkout github action in CI**
- **chore: Remove nightly lints that are not being tested**
- **chore: Remove unnecessary `cfg` due to MSRV increase**
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Considering eyre plans to release 1.0 some time soon
(https://github.com/eyre-rs/eyre/pull/269), it's a good time to clean up
the API
Having 2 macros that do the same thing leads to unnecessary churn in
which name to use.
That's why we should remove the `format_err!` macro.
It will also help prevent choice overload
`DefaultContext` and `EyreContext` exist as alias exports enabled by the
`anyhow` feature.
However, they are unused within `eyre`; neither are handlers of such
names exposed by `anyhow`.
This changeset removes both above mentioned handler aliases.
Closes [#135][135].
[135]: https://github.com/eyre-rs/eyre/issues/135
BREAKING CHANGE: The alias exports are undocumented but nevertheless
part of the crate's public API.
Noticed that the type annotation `(LineType, str)` was being used, but
in Python, this is interpreted as a regular tuple, not a proper type
hint. Switched it to `tuple[LineType, str]` for correctness.
[#131][131] introduced a new anyhow default feature flag to allow users
to hide aliased exports such as `eyre::Error` and `eyre::Context`.
This changeset removes `anyhow` from the list of default features,
making the compatibility layer with the anyhow crate opt-in.
Implements [#136][136].
[131]: https://github.com/eyre-rs/eyre/issues/131
[136]: https://github.com/eyre-rs/eyre/issues/136
BREAKING CHANGE: Removing a default feature is a breaking change.
The error reporting system now includes column number information
alongside line numbers in error reports and backtraces. This provides
more precise source location information, allowing developers to
immediately identify the exact column where an error occurred rather
than just the line number. This is especially helpful when multiple
issues exist on the same line.
Updated all theme test data files to match the new output format with
column numbers included.
<img width="1073" height="442" alt="image"
src="https://github.com/user-attachments/assets/6d2599fc-a0d2-4562-b73b-5ad36b7cb624"
/>
## Description
Hi! I fixed a broken link in `eyre/src/error.rs`. The previous link was
missing the file extension, causing it to fail.
Co-authored-by: Pavan K Sunkara <pavan.sss1991@gmail.com>
This pull request contains changes to improve clarity, correctness and
structure.
**Description correction:**
Corrected `comparision` to `comparison`
Please review the changes and let me know if any additional changes are
needed.
During a dependency review we noticed that the color-eyre crate includes
various development scripts. These development scripts shouldn't be
there as they might, at some point become problematic. As of now they
prevent any downstream user from enabling the `[bans.build.interpreted]`
option of cargo deny.
I opted for using an explicit include list instead of an exclude list to
prevent these files from being included in the published packages to
make sure that everything that's included is an conscious choice. I
decided to apply the settings to all workspace crates to make sure it
similar issues won't happen for the other crates in the future.
During a dependency review we noticed that the color-eyre crate includes various development scripts. These development scripts shouldn't be there as they might, at some point become problematic. As of now they prevent any downstream user from enabling the `[bans.build.interpreted]` option of cargo deny.
I opted for using an explicit include list instead of an exclude list to prevent these files from being included in the published packages to make sure that everything that's included is an conscious choice. I decided to apply the settings to all workspace crates to make sure it similar issues won't happen for the other crates in the future.
This commit introduces an explict `include` configuration in the
`Cargo.toml` file of `color-spantrace`. That has the effect that it now
excludes the two example images from the source code uploaded to
crates.io.
The main benifits of this change are:
* It reduces the size of the uploaded tar-ball from 186KB to 12KB, so an
over 90% reduction in size. That will reduce the traffic produced by
this crate at crates.io by over 350GB in a 90 day period based on the
number of downloads listed by crates.io
* It removes a hard to review binary blob from the source code. In
combination with the build script such a blob might enable a future
supply chain attack. By removing the blob it becomes at least harder to
perform a xz-like code injection.
The pictures are only used by the readme. That readme is rendered by
crates.io. To keep the rendering there intact the links to the image
have been replaced by linkes to the image hosted by github. This removes
the need to upload these images to crates.io.
owo-colors has a potential soundness bug, which I'm attempting to fix in
https://github.com/jam1garner/owo-colors/pull/131. However, a lot of
crates rely on the 3.x series, which may not get patched. Preemptively
updating them, would appreciate a release!!
