Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancing VTable Generation to Support Inherited Classes #2799

Open
ThalusA opened this issue Mar 30, 2024 · 1 comment
Open

Enhancing VTable Generation to Support Inherited Classes #2799

ThalusA opened this issue Mar 30, 2024 · 1 comment

Comments

@ThalusA
Copy link

ThalusA commented Mar 30, 2024

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).

@emilio
Copy link
Contributor

emilio commented Apr 1, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants