Fix extensible class inheritance: derived Lua method overwrites base class slot

[Copilot]

When same-named Lua methods were defined on both a base and derived extensible class, the derived method was silently stored in the base class table, causing base:init() to dispatch to Derived:init().

function Base:init()    print('Base:init()') end
function Derived:init() print('Derived:init()') end

local base = Base()
base:init()  -- was incorrectly calling Derived:init()

Root cause

try_call_newindex_extensible searched up the class hierarchy for an existing method, then stored the new value at whatever class table the search loop landed on — often the parent's. Additionally, when allowOverridingMethods was set and a C++ function was found in a parent, it was renamed in the parent table (super_<name>), breaking base-class instances that expected to call the original C++ function.

Fix (Source/LuaBridge/detail/CFunctions.h)

After the search loop, the storage location is chosen based on the type of value being assigned:

• Lua function values (method definitions such as function Derived:init()) — stored in the original (derived) class table, resolved via lua_getmetatable(L, 1) → push_class_or_const_table. This ensures each class has its own independent method slot and the derived method never pollutes the base class table.
• Non-function values (static properties such as Derived.property = 100) — stored at the original location (wherever the search loop ended). This preserves compatibility with classes that register a custom index fallback on a parent to handle per-instance storage: the fallback fires before rawget at that level, so the parent-stored property is correctly shadowed by the per-instance value.
• super_<name> copy — when a C++ cfunction is found in a parent and allowOverridingMethods is set, it is copied into the derived class table as super_<name> without modifying the parent. Base-class instances continue to find and call the original C++ function via their own class table.

Tests (Tests/Source/ClassExtensibleTests.cpp)

Three regression tests added:

• ExtensibleDerivedDoesNotPollutBaseMethod — the reported bug exactly
• ExtensibleDerivedMethodIsolatedFromBase — both classes dispatch to their own Lua method independently
• ExtensibleDerivedOverridePreservesCppBaseMethod — allowOverridingMethods override in derived class leaves the C++ base method intact for base instances

---

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

[kunitoki]

With this solution i get failures:

[ RUN      ] ClassExtensibleTests.IndexAndNewMetaMethodCalledInBaseClass
Tests/Source/ClassExtensibleTests.cpp:779: Failure
Expected equality of these values:
  102
  result<int>()
    Which is: 200

Tests/Source/ClassExtensibleTests.cpp:787: Failure
Expected equality of these values:
  3
  result<int>()
    Which is: 100

[  FAILED  ] ClassExtensibleTests.IndexAndNewMetaMethodCalledInBaseClass (0 ms)

[Copilot]

With this solution i get failures:

[ RUN      ] ClassExtensibleTests.IndexAndNewMetaMethodCalledInBaseClass...

Thank you for catching this. The fix has been revised (commit 614cc3f → branch updated).

Root cause of the regression: the previous fix unconditionally redirected all static writes to cl_derived. That caused DerivedExtensible.property = 100 (a non-function value) to land in cl_derived, where instance reads found it via rawget(cl_derived, "property") before reaching the parent's custom index fallback (NonExtensible's per-instance C++ storage).

Corrected approach — the new fix distinguishes two cases after the search loop:

1. Lua function values (function Derived:init()): stored in the original (derived) class table → fixes the reported inheritance bug.
2. Non-function values (Derived.property = 100): kept at the original storage location (wherever the search loop ended) → preserves the custom fallback behaviour for IndexAndNewMetaMethodCalledInBaseClass.

Results on Lua 5.2–5.5: all 28 tests pass. There is one remaining failure on Lua 5.1 only (IndexAndNewMetaMethodCalledInBaseClass) which appears to be a Lua-5.1-specific interaction between inherited custom index fallbacks and the class-table lookup order — I ran out of time to fully root-cause that; further investigation of Lua 5.1 behaviour needed.

[kunitoki]

Failure