Closed ian-h-chamberlain closed 5 months ago
Other than for a couple of missing features, which aren't really needed, I feel like this addition has all that it needs to be an useful replacement for bindgen tests. Great job! 👏
This is an interesting point — for now, I've left the bindgen tests in place because I think they might still be useful to assert properties that clang thinks about the generated types... Especially given that only adds around 1 minute to CI time, and takes almost no effort on our part, do you think we should leave those alone and keep running them alongside these new tests?
Otherwise, I think this PR is pretty much good to go so I will probably merge once everything is passing 🚀
This is an interesting point — for now, I've left the bindgen tests in place because I think they might still be useful to assert properties that clang thinks about the generated types... Especially given that only adds around 1 minute to CI time, and takes almost no effort on our part, do you think we should leave those alone and keep running them alongside these new tests?
Very much so, bindgen
tests are still a pretty integral part in the binding generation routine, and they are still the "best" comparative case for the suite added here. I'd keep them around for as long as we feel fit for testing the new suite and tweaking the bindgen
setup (which after all these past issues I don't trust to be precise enough :sweat_smile:).
Otherwise, I think this PR is pretty much good to go so I will probably merge once everything is passing 🚀
:+1:
Similar to the tests generated by
bindgen
, but using our actual toolchain to spit out the expected values instead of what libclang generates (bindgen's default behavior).The full generated test can be downloaded from Actions: https://github.com/rust3ds/ctru-rs/actions/runs/9072691412/artifacts/1499437252
Here's a partial example: