You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It'd be great if this crate could somehow issue a diagnostic indicating that there's no need to include the {0} in the #[error] because it's already rendered in the final error via #[from]
I was talking about this in Cranelift - thiserror includes the inner error for Debug output but not for Display. From my perspective this is a bug because I have no idea what actually went wrong in Display mode. Would it be possible to make the two implementions consistent? Either include the inner error in Display or do not include it in Debug
Reacted by jlgerber, Mikail Bagishov, mukund and Aworldc
I’m interested in trying to implement this. Looks like it would make the most sense to check after expanding display shorthand in Struct::from_syn and Enum::from_syn. Looks like for now the ability to issue warnings from a proc macro is nightly only, so I suppose this would just be proof-of-concept until that’s stabilized.
Activity
jyn514 commentedon Nov 17, 2019
I was talking about this in Cranelift - thiserror includes the inner error for Debug output but not for Display. From my perspective this is a bug because I have no idea what actually went wrong in Display mode. Would it be possible to make the two implementions consistent? Either include the inner error in Display or do not include it in Debug
alilleybrinker commentedon May 26, 2020
I’m interested in trying to implement this. Looks like it would make the most sense to check after expanding display shorthand in
Struct::from_synandEnum::from_syn. Looks like for now the ability to issue warnings from a proc macro is nightly only, so I suppose this would just be proof-of-concept until that’s stabilized.Use source attribute on wrapped errors