rust-bindgen icon indicating copy to clipboard operation
rust-bindgen copied to clipboard

Enhancing VTable Generation to Support Inherited Classes

Open ThalusA opened this issue 1 year ago • 1 comments

Input C/C++ Header

class IUnknown {
public:
    virtual void Release() {
        delete this;
    };
};

class iTH : public IUnknown {
public:
    virtual void AccessibleFunction() = 0;
};

class CTH: public iTH {
public:
    CTH() = default;

    void AccessibleFunction() override {};
};

iTH *CreateITH() {
    return (iTH *)(new CTH());
}

int main() {
    iTH *ptr = CreateITH();
    ptr->AccessibleFunction();
    ptr->Release();
    return 0;
}

Bindgen Invocation

bindgen::Builder::default()
    .header("input.h")
    .vtable_generation(true)
    .generate()
    .unwrap()

Actual Results

Currently, the vtable generation is limited to virtual classes without any base members.

Expected Results

The expectation is to extend vtable generation to support more complex class hierarchies.

Current Work Status

I'm in the process of addressing this issue through a PR. My aim is to remove the limitation preventing the generation from working with classes that have inheritance. However, I've encountered some hurdles along the way. It would be immensely helpful to connect with a maintainer of rust-bindgen to discuss the underlying architecture in more detail.

So far, I've made progress, but I've hit a roadblock. Specifically, I'm unsure how to access the comp_info of base members in order to retrieve their associated fields, types, and sizes. My goal is to associate a VTable declaration for each class with accurate information. Additionally, I aim to incorporate base member fields directly into each class, rather than adding base_XXX fields to each class (which occurs due to vtable merging).

ThalusA avatar Mar 30 '24 20:03 ThalusA

In general this seems like a feature worth implementing.

Specifically, I'm unsure how to access the comp_info of base members in order to retrieve their associated fields, types, and sizes.

Does something like:

let base_ty = ctx.resolve_item(base.ty).expect_type();

not work? From there you have the type (you could have an as_comp or so to get the compinfo). Depending on what you want to do with type aliases etc you might want to do something like base.ty.into_resolver().through_type_refs().resolve(ctx).expect_type();, but I might be missing something?

emilio avatar Apr 01 '24 20:04 emilio