Use of "rustified" enums in ctre-sys #1
Comments
|
So the intent would probably be to link to the static library. That way there wouldn't be any surprises for anyone using this crate. I'm still trying to figure out why I'm getting this link error though when building the example I have: (Update: I discovered that WPILib have had a hack for this dating back before 2015. Fun times.) The intent then would be that the crate versions follow the Phoenix version numbers. As for the plan for updates: I've modelled this off of how https://github.com/anguslees/rust-jsonnet is developed, in the hopes that CTRE don't drastically change the CCI layer. For the moment that seems pretty unlikely, other than changing the enum members — CTRE seem pretty happy with adding "versioned" APIs for the various functions. Note that I was unable to use rust-bindgen for the Logger bindings (at least not without a large amount of pain), and the CANifier and PigeonIMU headers needed patching before I could bindgen those. I should file an issue about the latter… There's probably a much better way of exposing the ErrorCode enum though, and I would appreciate any suggestions (that aren't too painful to implement). |
Avoid possible UB from the function possibly returning a value that is not in our enum variants. Ref: #1
|
Oh fun. Phoenix 5.7 has a thing to get all the configs. Thing is that it calls ConfigGetParameter, so it grabs doubles and casts them to the enums. So now we need some way of converting the discriminants of config-related enums to their corresponding variants. And I definitely don't want to write it all by hand. |
|
So I've proposed rust-lang/rust-bindgen#1669 with the intention of using it for ParamEnum at the very least, and maybe some of the other enums. Let's see where this goes. |
|
I did a thing to preserve the nice Debug on ErrorCode whilst making it a newtype. So now the only potential UB should be the bool pointers (which I am going to assume will never be assigned invalid bit-patterns by the Phoenix libraries). |
If the called C/C++ returns an enum out of the range of the defined rust enum, UB results.
Rust-bindgen has the constified enum variant, though its not as ergonomic. What is the current plan to deal with API/ABI breaking updates to Phoenix? Will someone have to comb through all the enums every time we want to update? That's why, personally, I much prefer generating bindings at compile time, and working around the results. Looking at the diffs of
rust-bindgens output and the current code, I don't know how big of a change that would be.The approach I took with
first-rust-competitionwas to use constified enums with a macro to make the identifiers more concise/DRY at the *-sys level. In the public API actual rust enums are used that implementInto<u32>(that's the plan anyway).The text was updated successfully, but these errors were encountered: