build(deps): update rust crate thiserror to v2 #130

renovate · 2024-11-11T00:35:05Z

This PR contains the following updates:

Package	Type	Update	Change	Pending
thiserror	dependencies	major	`1.0.59` -> `2.0.0`	`2.0.6`

Release Notes

dtolnay/thiserror (thiserror)

`v2.0.5`

Compare Source

Prevent deprecation warning on generated impl for deprecated type (#394)

`v2.0.4`

Compare Source

Eliminate needless_lifetimes clippy lint in generated From impls (#391, thanks @matt-phylum)

`v2.0.3`

Compare Source

Support the same Path field being repeated in both Debug and Display representation in error message (#383)
Improve error message when a format trait used in error message is not implemented by some field (#384)

`v2.0.2`

Compare Source

Fix hang on invalid input inside #[error(...)] attribute (#382)

`v2.0.1`

Compare Source

Support errors that contain a dynamically sized final field (#375)
Improve inference of trait bounds for fields that are interpolated multiple times in an error message (#377)

`v2.0.0`

Compare Source

Breaking changes

Referencing keyword-named fields by a raw identifier like {r#type} inside a format string is no longer accepted; simply use the unraw name like {type} (#347)

This aligns thiserror with the standard library's formatting macros, which gained support for implicit argument capture later than the release of this feature in thiserror 1.x.
```
#[derive(Error, Debug)]
#[error("... {type} ...")]  // Before: {r#type}
pub struct Error {
    pub r#type: Type,
}
```

Trait bounds are no longer inferred on fields whose value is shadowed by an explicit named argument in a format message (#345)

// Before: impl<T: Octal> Display for Error<T>
// After: impl<T> Display for Error<T>
#[derive(Error, Debug)]
#[error("{thing:o}", thing = "...")]
pub struct Error<T> {
    thing: T,
}

Tuple structs and tuple variants can no longer use numerical {0} {1} access at the same time as supplying extra positional arguments for a format message, as this makes it ambiguous whether the number refers to a tuple field vs a different positional arg (#354)
```
#[derive(Error, Debug)]
#[error("ambiguous: {0} {}", $N)]
//                  ^^^ Not allowed, use #[error("... {0} {n}", n = $N)]
pub struct TupleError(i32);
```
Code containing invocations of thiserror's derive(Error) must now have a direct dependency on the thiserror crate regardless of the error data structure's contents (#368, #369, #370, #372)

Features

Support disabling thiserror's standard library dependency by disabling the default "std" Cargo feature: thiserror = { version = "2", default-features = false } (#373)

Support using r#source as field name to opt out of a field named "source" being treated as an error's Error::source() (#350)

#[derive(Error, Debug)]
#[error("{source} ==> {destination}")]
pub struct Error {
    r#source: char,
    destination: char,
}

let error = Error { source: 'S', destination: 'D' };

Infinite recursion in a generated Display impl now produces an unconditional_recursion warning (#359)
```
#[derive(Error, Debug)]
#[error("??? {self}")]
pub struct Error;
```

A new attribute #[error(fmt = path::to::myfmt)] can be used to write formatting logic for an enum variant out-of-line (#367)

#[derive(Error, Debug)]
pub enum Error {
    #[error(fmt = demo_fmt)]
    Demo { code: u16, message: Option<String> },
}

fn demo_fmt(code: &u16, message: &Option<String>, formatter: &mut fmt::Formatter) -> fmt::Result {
    write!(formatter, "{code}")?;
    if let Some(msg) = message {
        write!(formatter, " - {msg}")?;
    }
    Ok(())
}

Enums with an enum-level format message are now able to have individual variants that are transparent to supersede the enum-level message (#366)

#[derive(Error, Debug)]
#[error("my error {0}")]
pub enum Error {
    Json(#[from] serde_json::Error),
    Yaml(#[from] serde_yaml::Error),
    #[error(transparent)]
    Other(#[from] anyhow::Error),
}