enum and define with the same name collide #687
Comments
|
That's... nasty... What would be a good solution for this? I can allow you to ignore a given macro by name with a new method in |
|
To be more clear, I'm thinking in something like with something like: enum MacroParsingBehavior {
TryToEvaluate,
Ignore,
}Or something like that. |
|
Thanks for your quick response! If i understand correctly, you're suggesting that i return In general, it feels like the two definitions should belong to two different namespaces, but i don't know enough about |
|
Yeah, it's a kind of unfortunate trade-off between ease to use and features... In general bindgen doesn't need to do a lot of deduplicating at the root level because rust allows to differentiate We could either mangle stuff like |
|
I've started seeing this behavior on bindgen 0.26. While bindgen 0.25 generated code without errors. Bindgen 0.26 started giving me errors: As a workaround I'm just ignoring those types: |
|
I've encountered the same error with |
I ran into this bug while compiling: rust-lang/rust-bindgen#687
|
Is there any update or progress on fixing this issue? I'm only affected by it via an external dependency so manually tweaking bindgen settings isn't really an option for me. And this is currently blocking a project 😞 |
|
I could imagine the Essentially, moving our method/function overloading strategy up and out of codegen and use it for all definitions. This should also solve #840 If anyone is interested in trying their hand at this, I can help mentor (cc @spacekookie ) |
|
I just noticed that there's a way to properly handling this hiding the enum instead of the constant with |
This is symmetric, yet less powerful, than enum_variant_behavior. Fixes rust-lang#687.
This is symmetric, yet less powerful, than enum_variant_behavior. Fixes rust-lang#687.
This is symmetric, yet less powerful, than enum_variant_behavior. Fixes rust-lang#687.
callbacks: Introduce MacroParsingBehavior to allow ignoring macros. This is symmetric, yet less powerful, than enum_variant_behavior. Fixes #687.
|
@bors-servo why is this closed? Still having those issues! |
|
Yes, but now you have a way to avoid them, using |
|
Hello @emilio , Can you please shed some lights on how to use However, none of them are part of my orginal C code. I'm wondering how can I fix this issue? Thanks much! |
|
You can either add a Or if you don't care about that particular enum either, you could do something like |
|
Hello @emilio , Thanks for the response. Now, I use I take a look at the bindings generated: /// Data used by Set Features / Get Features \ref SPDK_NVME_FEAT_ASYNC_EVENT_CONFIGURATION
#[repr(C)]
#[derive(Copy, Clone)]
pub union spdk_nvme_feat_async_event_configuration { pub raw: u32, pub bits: spdk_nvme_feat_async_event_configuration__bindgen_ty_1, _bindgen_union_align: u32 }
#[repr(C)]
#[derive(Copy, Clone)]
pub struct spdk_nvme_feat_async_event_configuration__bindgen_ty_1 { pub crit_warn: spdk_nvme_critical_warning_state, pub _bitfield_1: __BindgenBitfieldUnit<[u8; 4usize], u32>, pub __bindgen_align: [u32; 0usize] }The original data structure in C looks like /**
* Data used by Set Features / Get Features \ref SPDK_NVME_FEAT_ASYNC_EVENT_CONFIGURATION
*/
union spdk_nvme_feat_async_event_configuration {
uint32_t raw;
struct {
union spdk_nvme_critical_warning_state crit_warn;
uint32_t ns_attr_notice : 1;
uint32_t fw_activation_notice : 1;
uint32_t telemetry_log_notice : 1;
uint32_t reserved : 21;
} bits;
};There is also an assertion immediately follows the struct definition above: The full stacktrace I got for the error: Here is the assertion failure: The corresponding test is #[test]
fn bindgen_test_layout_spdk_nvme_feat_async_event_configuration() {
assert_eq!(::std::mem::size_of::<spdk_nvme_feat_async_event_configuration>(), 4usize, concat!( "Size of: " , stringify ! ( spdk_nvme_feat_async_event_configuration ) ));
assert_eq!(::std::mem::align_of::<spdk_nvme_feat_async_event_configuration>(), 4usize, concat!( "Alignment of " , stringify ! ( spdk_nvme_feat_async_event_configuration ) ));
assert_eq!(unsafe { &(*(::std::ptr::null::<spdk_nvme_feat_async_event_configuration>())).raw as *const _ as usize }, 0usize, concat!( "Offset of field: " , stringify ! ( spdk_nvme_feat_async_event_configuration ) , "::" , stringify ! ( raw ) ));
assert_eq!(unsafe { &(*(::std::ptr::null::<spdk_nvme_feat_async_event_configuration>())).bits as *const _ as usize }, 0usize, concat!( "Offset of field: " , stringify ! ( spdk_nvme_feat_async_event_configuration ) , "::" , stringify ! ( bits ) ));
}Is there anything special I should pay attention regarding Thanks! |
|
Hi @xxks-kkk, that makes sense. Those tests failing mean that the struct is unsafe to use from Rust. The other case looks a bit more problematic. You can mark them as opaque (via Mind filing a new issue about that, with the code snippet you posted plus the definition of |
|
Yes, opaque_type will make it sort of unusable inside rust, it'll make it a blob of bytes. |
|
For future discoverers of this issue, I'm using this code: #[derive(Debug)]
struct IgnoreMacros(HashSet<String>);
impl bindgen::callbacks::ParseCallbacks for IgnoreMacros {
fn will_parse_macro(&self, name: &str) -> bindgen::callbacks::MacroParsingBehavior {
if self.0.contains(name) {
bindgen::callbacks::MacroParsingBehavior::Ignore
} else {
bindgen::callbacks::MacroParsingBehavior::Default
}
}
}Initialized as let ignored_macros = IgnoreMacros(
vec![
"FP_INFINITE".into(),
"FP_NAN".into(),
"FP_NORMAL".into(),
"FP_SUBNORMAL".into(),
"FP_ZERO".into(),
"IPPORT_RESERVED".into(),
]
.into_iter()
.collect(),
);and called as .header("wrapper.h")
.parse_callbacks(Box::new(ignored_macros))
.rustfmt_bindings(true) |
|
Reproduced this issue. What's the workaround of it? |
|
Check out @stillinbeta's comment #687 (comment). |
|
Thank you! |
|
@db48x How to apply that snippet? |
Running into these issues: rust-lang/rust-bindgen#687 Signed-off-by: William Casarin <jb55@jb55.com>
|
Slightly tweaked version, and including const IGNORE_MACROS
: [&str; 20] = [
"FE_DIVBYZERO",
"FE_DOWNWARD",
"FE_INEXACT",
"FE_INVALID",
"FE_OVERFLOW",
"FE_TONEAREST",
"FE_TOWARDZERO",
"FE_UNDERFLOW",
"FE_UPWARD",
"FP_INFINITE",
"FP_INT_DOWNWARD",
"FP_INT_TONEAREST",
"FP_INT_TONEARESTFROMZERO",
"FP_INT_TOWARDZERO",
"FP_INT_UPWARD",
"FP_NAN",
"FP_NORMAL",
"FP_SUBNORMAL",
"FP_ZERO",
"IPPORT_RESERVED",
];
#[derive(Debug)]
struct IgnoreMacros(HashSet<String>);
impl ParseCallbacks for IgnoreMacros {
fn will_parse_macro(&self, name: &str) -> MacroParsingBehavior {
if self.0.contains(name) {
MacroParsingBehavior::Ignore
} else {
MacroParsingBehavior::Default
}
}
}
impl IgnoreMacros {
fn new() -> Self {
Self(IGNORE_MACROS
.into_iter().map(|s| s.to_owned()).collect())
}
}And usage .parse_callbacks(Box::new(IgnoreMacros::new()))
// Longdouble creates warnings about 16-bit numbers, good to ignore if relevant
.blocklist_function("strtold")I wonder if |
|
I see this issue is labeled is closed and was "fixed" by another PR, but it must have regressed. I used the same header and bindgen 0.65.1, and it gave me almost the exact same error. I can post more details if necessary. |
|
This issue has not regressed, what happens is that there is no magic solution for it. As mentioned https://github.com/rust-lang/rust-bindgen/issues/687#issuecomment-416537395, you need to either block the macro or the enumerator. A more in-depth explanation is given here. |
Input C/C++ Header
Bindgen Invokation
Actual Results
Expected Results
No compilation error, both the enum and the define have their own name space.
This is problematic IRL because
math.huses this construct to defineFP_*constants:https://sourceware.org/git/?p=glibc.git;a=blob;f=math/math.h;h=cfaed0ed98013830421afdf1ba6f13c01702831d;hb=HEAD#l318
RUST_LOG=bindgenOutputThe text was updated successfully, but these errors were encountered: