4 curated breaking changes across major versions of thiserror-impl. Use this as a migration checklist before bumping dependencies.
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. ```rust #[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) ```rust // 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) ```rust #[derive(Error, Debug)] #[error("ambiguous: {0} {}", $N)] // ^^^ Not allowed, use #[error("... {0} {n}", n = $N)] pub struct TupleError(i32); ```
Get this data programmatically \u2014 free, no authentication.
curl https://depscope.dev/api/breaking/cargo/thiserror-implCode 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)