Is your feature request related to a problem? Please describe.
Currently, our error types do not use external crates, which forces us to implement traits such as Display manually and adds a lot of boilerplate code.
This was unavoidable, as the Error trait that most error handling libraries are based on was part of std up until recently, which prevented using them in no_std environments.
Describe the solution you'd like
As the Error trait will be moved to core with the next stable Rust release (rust-lang/rust#103765) and will therefore be available in no_std environments, we should reconsider the usage of error handling crates in order to remove some boilerplate.
As thiserror is one of the most widely used rust crates for this purpose, it would make sense to use it as soon as it also supports no_std (dtolnay/thiserror#304).
Describe alternatives you've considered
We could also keep the existing code and not switch to thiserror.
This would allow us to keep supporting older Rust versions (using thiserror with no_std would probably require a MSRV bump to 1.81), but we will have to maintain our error types manually.
Is your feature request related to a problem? Please describe. Currently, our error types do not use external crates, which forces us to implement traits such as
Displaymanually and adds a lot of boilerplate code. This was unavoidable, as the Error trait that most error handling libraries are based on was part ofstdup until recently, which prevented using them inno_stdenvironments.Describe the solution you'd like As the
Errortrait will be moved tocorewith the next stable Rust release (rust-lang/rust#103765) and will therefore be available inno_stdenvironments, we should reconsider the usage of error handling crates in order to remove some boilerplate.As thiserror is one of the most widely used rust crates for this purpose, it would make sense to use it as soon as it also supports
no_std(dtolnay/thiserror#304).Describe alternatives you've considered We could also keep the existing code and not switch to thiserror. This would allow us to keep supporting older Rust versions (using
thiserrorwithno_stdwould probably require a MSRV bump to 1.81), but we will have to maintain our error types manually.