ImDrawListSharedData not generated correctly when generating dcimgui.h

[ZimM-LostPolygon]

Trying to update to 1.92.x and keep hitting more edge cases.

ImDrawListSharedData struct is defined in imgui_internal.h while being used all throughout imgui.h. However, since normally only imgui.h is included when processing imgui.h, what ends up happening is that dear_bindings never knows nothing about ImDrawListSharedData except for the mere fact it exists, so the type is silently emitted as empty, with no fields:

{
    "name": "ImDrawListSharedData",
    "original_fully_qualified_name": "ImDrawListSharedData",
    "kind": "struct",
    "by_value": false,
    "has_placement_constructor": false,
    "forward_declaration": true,
    "is_anonymous": false,
    "fields": [],
    "comments": {
        "attached": "// Data shared among multiple draw lists (typically owned by parent ImGui context, but you may create one yourself)"
    },
    "is_internal": false,
    "source_location": {
        "filename": "imgui.h",
        "line": 171
    }
},

Honestly, not sure if this just wasn't noticed before, or it is a result of recent-ish changes, but the way dear_bindings works, it expects ImDrawListSharedData to be fully defined in imgui.h.

Possible solutions/workarounds:

1. ImDrawListSharedData's definition is moved from imgui_internal.h to imgui.h in dear imgui itself
2. Include imgui_internal.h even if only intending to generate a wrapper for imgui.h. EDIT: this should work, but somehow doesn't. ImDrawListSharedData is still empty in every generated file

---

Are there any other types that behave weirdly like that? Are we able to detect those cases and throw an error instead of silently outputting invalid output?

[ShironekoBen]

So from a quick glance that output looks "right" to me for imgui.h - forward_declaration is set to true, which is Dear Binding's way of indicating that this is a type that it knows exists (and can thus declare pointers to, in classic C style), but doesn't have any other information on.

Is the scenario where this causes a problem one where just ignoring types in the metadata with forward_declaration set would fix it? (or treating such types as "I know there's an opaque thing called ImDrawListSharedData that it's possible to have a pointer to, but I can't do anything else with it"?) Or is it a deeper issue where you need the full structural definition (but without pulling in the full imgui_internal.h metadata)?

[ZimM-LostPolygon]

Hm... It's a little bit of both. When there is truly no information about the type, I do treat it as an opaque pointer. Examples would be numerous external API types in backend code, like SDL_Event, GLFWmonitor, ID3D12Device and such. However that approach doesn't really work for me in this case, as ImDrawListSharedData can now flip-flop between being fully declared or not depending on if imgui_internal.h is included.

Here's my conundrum:
I want to make 2 separate wrapper libraries, one for imgui.h, and the other for imgui_internal.h. The imgui_internal.h wrapper depends on the wrapper for imgui.h, but not the other way around. That way, if a consumer of the wrapper library has no intent on using internal things, they can only include the wrapper for imgui.h. So far so good, ImDrawListSharedData* can be treated as an opaque pointer. But then, one day, the user decided to also use some internal things, so they add the internals wrapper. And at this point, each wrapper library has its own version of ImDrawListSharedData - one that's empty, and other that's fully defined, except the non-internal wrapper still always returns the opaque pointer version, and now the user of the wrapper has to know the difference and manually convert between the two... Or the internal wrapper could add a bunch of manually written functions that are saying "hey, if you have this opaque pointer from this place, call me to actually access the data". Less than ideal.

Not sure if my rambling makes sense here, and on a second thought, I agree that the current behavior is technically correct. It's just that it makes it impossible to make the wrapper for imgui.h a fully self-contained one. It's almost like there can only be two variants of the wrapper:

1. Wrapper library for imgui.h that knows nothing about internal stuff.
2. Combined wrapper library for imgui.h+imgui_internal.h that knows about both public and internal stuff.

And it's not possible to make a self-contained imgui.h wrapper that imgui_internal.h can fully depend on with no overlap