What we need to see is how we implement the usual custom and reserved variants, which were manually implemented for McdReturnError. Check the equivalent definition of mcd_return_et. These variants are not actually rust variants, but boundaries for custom variants. Three options we have, which are all good:
Do not handle these variants - which is acceptable because there will never be variants in the "custom" range. To my understanding, this is meant to be used by users of the library to use the same type in their code, thanks to rust we don't have to do that. It is acceptable because it is unlikely that we ever encounter a "reserved" error code.
Build a derive macro that derives something allong the following trait:
/// Error code completely unknown, should never be reported by MCD
struct UnknownCode;
/// Codes that MCD can report but we can't really handle
enum McdUnhandledCodes {
Reserved(u32)
Custom(u32)
}
The final enumerations would still contain e.g. the `_RESERVED_LO` and `_RESERVED_HI` variants, which is not perfect.
3. Keep a manual definition of enumerations in sync in the rust library. This is somewhat tedious, manual work but it would only have to be done once and with better binding generation this will be much easier than it already is.
The current MCD bindings only contain anonymous enumerations. This converts all variants to constants which make it hard to manage and use in rust. With a bit of preprocessing of the header file, bindgen could be able to produce rust enumerations, e.g. compare https://github.com/veecle/tricore-probe/blob/b035ad3a51a1e6b18438929462a112c0d20c13ef/rust-mcd/mcd_demo_basic_120412/src/mcd_api.h#L214-L224 with the rust equivalent https://github.com/veecle/tricore-probe/blob/b035ad3a51a1e6b18438929462a112c0d20c13ef/rust-mcd/src/raw/mod.rs#L12-L25
Check https://github.com/therealfrauholle/tricore-probe/commit/55ba68620f02e684a0e543a1ae0a53ce6b957373 for a prototyped implementation. I preprocessed the headerfile manually (actually, with a regex); I believe this should actually happen within the buildscript and we should not touch the header files directly.
What we need to see is how we implement the usual custom and reserved variants, which were manually implemented for
McdReturnError. Check the equivalent definition ofmcd_return_et. These variants are not actually rust variants, but boundaries for custom variants. Three options we have, which are all good:/// Codes that MCD can report but we can't really handle enum McdUnhandledCodes { Reserved(u32) Custom(u32) }
trait UnhandledCodes { fn try_from(code: u32) -> Result<Result<Self, McdUnhandledCode>, UnknownCode>; }