Don't traverse through special-cased <stdint.h> types. by goffrie · Pull Request #2287 · rust-lang/rust-bindgen (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation3 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Fixes #1663.
Not sure if this is too special-casey, but there's already a bunch of this stuff strewn about. Seems like it would be cleanest to add a new TypeKind
for stdint types populated in from_clang_ty
but that seemed like a ton of work for relatively little gain.
Thanks for your PR!
I tried to do a mini test about this using b5ec18e and found that:
typedef unsigned long long uint64_t;
uint64_t foo();
emits the following rust code:
/* automatically generated by rust-bindgen 0.60.1 */
extern "C" { pub fn foo() -> u64; }
Do you have an extra example showing how your changes affect this behavior so we can add it as a test?
pvdrz mentioned this pull request
I added a test that demonstrates the issue. The key is to have a two-layer typedef: typedef unsigned long long __uint64_t; typedef __uint64_t uint64_t;
Without this PR, an extraneous type __uint64_t = ::std::os::raw::c_ulonglong;
is emitted.
Looks good to me! Thanks!
2 participants