Conversation
|
Seems like the type drama in the tests was "just" caused by having some dependencies not updated (falling back to older versions). There might still be flip-flopping (cty on ARM has c_char = u8, core::ffi has c_char = i8), but given that all Rust code must support either already anyway, maybe it's not even a breaking change in some sense. |
As the types re-exported from there are aliases to the native types (i8 etc) and not newtypes, they can compatibly be replaced with their now-stdlib definitions.
Now that a recent change made 1.64 mandatory, this can just as well be done now.
|
Rebased now that #66 is opening the 'breaking change' box. As the previous merge conflict indicates, this might also be a good occasion to revisit whether |
In addition to the previous PRs, this now also pulls in RIOT-OS/rust-riot-sys#14, which is also expected to be only technically breaking, and in particular not breaking riot-wrappers or code based on it.
In addition to the previous PRs, this now also pulls in RIOT-OS/rust-riot-sys#14, which is also expected to be only technically breaking, and in particular not breaking riot-wrappers or code based on it.
In addition to the previous PRs, this now also pulls in RIOT-OS/rust-riot-sys#14, which is also expected to be only technically breaking, and in particular not breaking riot-wrappers or code based on it.
|
I've given this some testing through RIOT-OS/rust-riot-wrappers#154 and trying it on the riot-examples, so I think this is the right path -- and now that 0.8 is in main, it is becoming mergeable. It seems we've already been through all possible breakage of char being signed on some platforms and unsigned on others (which is what I feared would be the fallout of this). I'll defer the size_t_is_usized revisiting for another PR. |
2 participants
Given that this introduces yet another round of "signed vs unsigned char" errors on ARM architectures, this probably needs to sit and wait for a large breaking change. It's probably worth just biting through that once...