You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should generate bitfield enum. I figured out that changing the invocation to
let bindings = bindgen::Builder::default().header("test.hpp").parse_callbacks(Box::new(RenameCallbacks{})).whitelist_type("Test").bitfield_enum("AnotherName").generate().expect("Couldn't generate bindings!");
will generate expected bindings.
This may not be a bug but it is definitely not documented. And it seems inconsistent with other APIs, since other APIs like whitelist_type() asks for name before parse_callbacks processing.
The text was updated successfully, but these errors were encountered:
I searched through the code base and issues a little bit and found #1125 and #1162 , and it seems that whitelist/blacklist was using canonical_path at that time. Now that whitelist/blacklist has moved away from that, should canonical_path be completely removed from the code base? The only other occurrence of canonical_path is
There are multiple occurrences of both canonical_path and namespace_aware_canonical_path in src/codegen/mod.rs (as expected, as that's the "final" path we generate code for).
However yes, I think that code should probably also be using path_for_whitelisting and so on.
Input C/C++ Header
enum Test { OptionA, OptionB, OptionC };
Bindgen Invocation
Actual Results
Expected Results
Should generate bitfield enum. I figured out that changing the invocation to
will generate expected bindings.
This may not be a bug but it is definitely not documented. And it seems inconsistent with other APIs, since other APIs like
whitelist_type()
asks for name beforeparse_callbacks
processing.The text was updated successfully, but these errors were encountered: