-
Notifications
You must be signed in to change notification settings - Fork 11
fix bindgen #116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix bindgen #116
Conversation
Oh right, I forgot I did a bunch of manual cleanup on the generated bindings. Thanks for documenting the steps.
I got rid of all I also replaced all For types like Remove Also if you don't mind, move structs like With these cleanups it should be easy to see if anything changed in the bindings unexpectedly. Actually I don't think much should change in the actual types, it's the layout tests that changed. I don't think we need to regen this often, so it's fine that more manual work is involved. Actually I doubt we'll have to regen this for a while if at all because the major problem with bindgen layout tests had been fixed now with |
Take a look again and see. Doesn't seem to have any problem loading and interacting with a TAS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, looks much better. Left some suggestions and comments
Thanks, I hope I didn't break anything with those last changes |
Bindgen 0.71 and latest rust nightly version.
Bindgen does not right away so there are some changes to bindgen such as
c_uint
toc_int
or*mut T
to*const T
. With that, bxt-rs code can remain unchanged. Bindgen also makes function type to beOption<unsafe extern ...>
instead of the usualunsafe extern ...
. So, for some parts, I add.unwrap()
wherever applicable. There are a lot of changes needed doing after generating bindings so I write all instructions along with the bindgen command inside each binding files.Some files are deleted because the new bindgen conveniently generates bunch of related structs. There are some re-declared structs such as
hull_s
where its members are defined in some files and not defined in some files. Doesn't seem like a problem.I am able to load a TAS and interact with the editor just fine. If anything to worry about, it is the
tas_server_time_fix
because there is a small change to the code that does pointer comparison. Though the changed code is from rust_analyzer suggestion so I guess it is all okay.