Falls back to BindgenUnion if a field is array of blacklisted type

[faern]

When I blacklist a type (because I want to import it from libc, not have it generated in my bindings.) Then bindgen fails to generate a union if a field in the C union has a field being an array of the blacklisted type, but not if the field has the same type, but isn't an array.

Input C/C++ Header

Correctly generats a union:

typedef int __u32;
union my_union {
    __u32       number;
};

Instead generates a BindgenUnion:

typedef int __u32;
union my_union {
    __u32       number[4];
};

Bindgen Invocation

$ bindgen union.h --blacklist-type __u32 --raw-line 'use libc::__u32;'

Actual Results

With first input header (no array):

#[repr(C)]
pub union my_union {
    pub number: __u32,
    _bindgen_union_align: u32,
}

With second input header, having an array in the union.

#[repr(C)]
pub struct my_union {
    pub number: __BindgenUnionField<[__u32; 4usize]>,
    pub bindgen_union_field: [u32; 4usize],
}

Expected Results

Both __u32 and [__u32; 4usize] should implement Copy and thus both should yield a union in the generated code.

EDIT: I'm using bindgen 0.32.1

[fitzgen]

Thanks for the bug report! Have you tried specifying a newer --rust-target? I think things may be working as expected here: pessimistically assuming support for older Rust versions.

[faern]

I get the same code (struct instead of union) when specifying --rust-target nightly (and 1.19 and 1.21) as well.

[faern]

If it were assuming support for older Rust versions, then why would it give me a real Rust union with one of the input headers? Did something change after 1.19 regarding what was possible to do inside a union?

[fitzgen]

If it were assuming support for older Rust versions, then why would it give me a real Rust union with one of the input headers? Did something change after 1.19 regarding what was possible to do inside a union?

I just didn't read carefully enough.

[jcranmer]

I started filing a bug until I realized that it was the same problem as this one.

Another way this crops up is if you have a typedef that goes through a blacklisted type:

typedef unsigned long long __uint64;
typedef __uint64 uint64_t;
struct S {
  union A {
    uint64_t val;
  } foo;
} bar;

(with _.* as the blacklist).

[emilio]

I think this can be easy-ish to fix fwiw. The reason this happens is here:

https://github.com/rust-lang-nursery/rust-bindgen/blob/d7a74baf5c822e0312aca539c3836e5d87c6091b/src/ir/analysis/derive_copy.rs#L133

I don't know if we can stop making that assumption easily, but it sounds plausible, and reasonable since you can explicitly make types not Copy by name in the same way you blacklist stuff, so probably keeping the two concepts separated makes sense.