Skip to content

Model multiple-inheritance vtbl bases as ABI-correct subobjects#750

Merged
tannergooding merged 1 commit into
dotnet:mainfrom
tannergooding:tannergooding-multibase-vtbl-subobjects
Jul 13, 2026
Merged

Model multiple-inheritance vtbl bases as ABI-correct subobjects#750
tannergooding merged 1 commit into
dotnet:mainfrom
tannergooding:tannergooding-multibase-vtbl-subobjects

Conversation

@tannergooding

Copy link
Copy Markdown
Member

A struct deriving from two or more polymorphic bases previously flattened every base into a single lpVtbl, which emitted duplicate members (a CS0111 compile error) and silently dispatched secondary-base methods through the primary vtable. This builds on #748 (the interim dedupe) and makes the layout ABI-correct.

Only the primary (first) polymorphic base shares the derived type's vtable pointer, so it alone is flattened into lpVtbl; every other polymorphic base is emitted as a nested subobject field, preserving its own vtable pointer at the correct offset. A field-bearing polymorphic primary base cannot be flattened and is likewise emitted as a subobject, so the derived type declares no lpVtbl of its own.


Nested multiple inheritance would require carrying a flattened base's own non-primary polymorphic subobjects onto the derived type. Faithfully modeling that needs changes to the generator's naming and base-field/dispatch resolution (both assume every emitted base is a direct base of the record), so it is deferred. Those records fall back to the legacy run-on lpVtbl -- every inherited method stays reachable so the bindings still compile -- and are flagged with a warning rather than silently mislaid out.

Known limitations (deferred, tracked for follow-up):

  • Nested multiple inheritance -> legacy run-on lpVtbl + warning.
  • Virtual/diamond inheritance (CXXBaseSpecifier.IsVirtual) is not modeled anywhere in the generator (pre-existing, orthogonal).

Validation:

  • Full generator suite green (Failed: 0), zero golden churn.
  • Added regression coverage in MultipleBaseVtblSubobjectTest.cs: secondary-base subobject (unifying and non-unifying), explicit-vtbl and marker-interface variants, field-bearing primary, and the nested-MI fallback (asserts the warning).
  • Self-hosted bindings contain no multi-base polymorphic structs, so no regeneration is required.

Fixes #592

A struct deriving from two or more polymorphic bases previously flattened every
base into a single `lpVtbl`, which emitted duplicate members (a CS0111 compile
error) and silently dispatched secondary-base methods through the primary vtable.

Only the primary (first) polymorphic base shares the derived type's vtable
pointer, so it alone is flattened into `lpVtbl`; every other polymorphic base is
emitted as a nested subobject field, preserving its own vtable pointer at the
correct offset. A field-bearing polymorphic primary base cannot be flattened and
is likewise emitted as a subobject, so the derived type declares no `lpVtbl` of
its own.

Nested multiple inheritance would require carrying a flattened base's own
non-primary polymorphic subobjects onto the derived type, which is not yet
modeled; those records fall back to the legacy run-on `lpVtbl` (keeping every
inherited method reachable) and are flagged with a warning.

Fixes dotnet#592

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@tannergooding tannergooding merged commit f6e6ca9 into dotnet:main Jul 13, 2026
14 checks passed
@tannergooding tannergooding deleted the tannergooding-multibase-vtbl-subobjects branch July 13, 2026 17:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Struct with two or more bases will have duplicate member names

1 participant