Do not generate names for typedefed anonymous structs and enums

[jethrogb]

A common pattern in a lot of C code is to do

typedef struct /* no name here */ {
    // ...
} my_struct;

bindgen 0.20 translates this using a made-up type name and a re-export. This makes the rustdoc documentation look awful (and potentially error messages as well). These bogus type names were not introduced in bindgen 0.19. I think there is no reason not to detect this common pattern and avoid them.

[emilio]

The thing is that detecting this common pattern is not that easy in the case of C++. Old bindgen did this looking at the AST of libclang, and got it wrong a lot of times, over all in presence of anonymous structs in classes (which I believe are also legal in C11).

I'm not really fond in supporting this. What we could do, is using a type alias instead of a re-export. The re-exports are done for convenience when using enums (#396), but we can definitely make it configurable.

[emilio]

BTW, thanks for filling all these issues, they're really helpful.

[jethrogb]

I don't think type aliases would fix the documentation or the error messages.

pub struct bindgen_ty {
    pub a_field: u32
}
pub type Typed = bindgen_ty;
pub use bindgen_ty as Used;

fn main() {
    let t: Typed = Typed{a_field:2};
    t.not_a_field;
    let u: Used = Used{a_field:2};
    u.not_a_field;
}

error: no field `not_a_field` on type `bindgen_ty`
 --> <anon>:9:7
error: no field `not_a_field` on type `bindgen_ty`
  --> <anon>:11:7

Besides, type aliases are not the same as re-exports. Crucially, tuple-struct constructors are not available through a type alias.

[jethrogb]

What's hard about this? Is such a definition split into two AST nodes with an anonymous struct definition and a related typedef?

[jethrogb]

BTW, thanks for filling all these issues, they're really helpful.

Thanks for being so receptive of my issues! Otherwise I'm pretty happy with the new features such as string macros, 128-bit integer support, probably more...

[emilio]

What's hard about this? Is such a definition split into two AST nodes with an anonymous struct definition and a related typedef?

Yes, I remember it being specially tricky to handle correctly under some circumstances in C++, that's why I used this approach.

[emilio]

TL;DR: This is how the simplest case looks like:

(kind: StructDecl, spelling: , type: Record
)
(kind: TypedefDecl, spelling: Foo, type: Typedef
	(kind: StructDecl, spelling: , type: Record
	)
)

That is, first we find the anonymous struct, then we find a typedef declaration that happens to contain a node pointing to that same struct. I guess I could try to handle it somewhat correctly given the definition of the anonymous struct (I expect) points to the inner item, but it's tricky.

[emilio]

I hadn't look into this for a while, actually doesn't look that terrible if what I say above is true, we could try to special-case this. But need to see how more complex cases are handled.