Clang 3.8.1 fails when mangling constructors and destructors

[rpjohnst]

Using Clang 3.8.1, bindgen fails an LLVM assert when given a constructor. A cursory look into the source around the assert suggests that it's somehow calling mangleCXXName rather than mangleCXXCtor, though I don't why that would happen on 3.8.1 but not 3.9.0.

I'm stuck on 3.8.1 because 3.9.0 renamed some intrinsics used by the headers I'm trying to run through bindgen. If this is one of the features that needs to be disabled for LLVM <3.9, I couldn't figure out how- I tried disabling constructors/destructors and ignoring methods, but those options don't seem to take effect early enough.

It does look like 3.9 also introduced several APIs that bindgen has been using for a while, so maybe this isn't really feasible to fix, but perhaps someone else has run into this.

Input C/C++ Header

struct Foo { Foo(); };

Bindgen Invokation

bindgen::builder()
    .header("input.h")
    .generate().unwrap()

Actual Results

The assertion at tools/clang/lib/AST/ItaniumMangle.cpp:4038 fails:

!isa<CXXConstructorDecl>(D) && !isa<CXXDestructorDecl>(D) && "Invalid mangleName() call on 'structor decl!"

This happens on (at least) 64-bit Windows and 64-bit Linux builds of Clang.

RUST_LOG=bindgen Output

There doesn't appear to be any, though I could be doing something wrong (it's just run through a normal cargo build script).

[emilio]

Ugh... Yeah, we've had mangling problems on windows before, see #69, #504, and others I'm probably forgetting about.

This seems windows specific, given I've definitely used bindgen with libclang 3.8 on Linux. I don't have a windows machine though...

[rpjohnst]

I looked into this a bit more and Clang 3.8.1 hits the same assert on Linux.

The problem seems to be that, pre-3.9.0, clang_Cursor_getMangling does not support constructors or destructors, presumably because a single definition actually produces multiple implementations and thus multiple mangled names. There is, for example, an alternate function clang_Cursor_getCXXManglings that does handle constructors and destructors.

For reference, as of 3.9.0 Clang simply picks the "complete constructor" (or destructor). The other possibilities for the constructor are the "base constructor" or the "allocating constructor," while the other possibilities for the destructor are the "base destructor" or the "deleting destructor."

[emilio]

Hmm.. So we do have a hack in cursor_mangling to generate the proper symbol because tests were failing in clang 3.8 on travis (the travis clang gave us the allocating constructor).

That's indeed a more elegant way to solve it, but I'm still fascinated by us not hitting the assert neither on CI nor on my machine... shrug.

[emilio]

Just checked, we download a release version, probably without assertions... Will fix this, nice suggestion with clang_Cursor_getCXXManglings

[emilio]

Got a patch up at #657. Waiting on CI now, but if you want to give it a try first that'd be appreciated (specially if you're on windows!)

[rpjohnst]

It seems to work for me on Windows.

On the Microsoft ABI, Clang doesn't ever output multiple destructor names: https://github.com/llvm-mirror/clang/blob/master/lib/Index/CodegenNameGenerator.cpp#L100

However, above that line, it looks like it might output an extra constructor in some cases (Ctor_DefaultClosure)? I suspect fully handling this would involve a new API in libclang to ask for a particular variant of the constructor.

[emilio]

yeah, right, the constructor is what worried me... (misspelled that comment, "the last destructor" should have been "the last mangling")

[rpjohnst]

To confirm, it looks like that extra constructor case is the "default constructor closure," which is generated when dllexporting a default constructor that requires some extra code to call, and the clang_Cursor_getCXXManglings solution handles it incorrectly.

For example, this code generates two constructor, with symbols ??0Foo@@QEAA@H@Z (public: __cdecl Foo::Foo(int)) and ??_FFoo@@QEAAXXZ (public: void __cdecl Foo::`default constructor closure'(void)).

struct __declspec(dllexport) Foo {
    Foo(int x = 3);
};

Bindgen declares the first but gives it the link_name of the second:

extern "C" {
    #[link_name = "??_FFoo@@QEAAXXZ"]
    pub fn Foo_Foo(this: *mut Foo, x: ::std::os::raw::c_int);
}