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.
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="...")]pubstructError<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)]pubstructTupleError(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)
