From a76b6ff458794a5f41cc0e0cb117120e101288f7 Mon Sep 17 00:00:00 2001 From: sei-eschwartz <50171988+sei-eschwartz@users.noreply.github.com> Date: Wed, 20 Mar 2024 23:02:29 +0000 Subject: [PATCH] Add several improvements to DerivedClass_F --- share/prolog/oorules/rules.pl | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/share/prolog/oorules/rules.pl b/share/prolog/oorules/rules.pl index e2a4472a..b6b093ca 100644 --- a/share/prolog/oorules/rules.pl +++ b/share/prolog/oorules/rules.pl @@ -1938,15 +1938,26 @@ DerivedClass, BaseClass, Offset)]). % An easier to understand version of E that builds on concluded VBTable facts instead of RTTI. +reasonDerivedClass_F(DerivedClass, BaseClass, Offset) :- reasonDerivedClass_F(DerivedClass, BaseClass, Offset) :- factObjectInObject(DerivedClass, BaseClass, Offset), % There's an entry in some VBTable somehere (only unified by Offset so far). - factVBTableEntry(VBTableAddress, _TableObjectOffset, Offset), + factVBTableEntry(VBTableAddress, TableOffset, OffsetFromVBPtr), + % The first offset of a VBTable is the offset from the vbptr to the object start. + TableOffset > 0, % And that VBTable is installed into an object in some Method. - factVBTableWrite(_Insn, Method, _VBTableOffset, VBTableAddress), + factVBTableWrite(_Insn, Method, VBPtrOffset, VBTableAddress), + % Ensure that BaseClass is not empty. If it is, there could be multiple + % classes at the same offset. + notEmptyClass(BaseClass), % Finally, check that the method is assigned to the Derived class. % This is the unification that makes the VBTableEntry relevant. find(Method, DerivedClass), + + % ejs 8/13/22 The offsets in a vbtable are offsets from the location of the vbptr, not from + % the beginning of the class. Sometimes the vbptr is at offset zero, but not always. + Offset is OffsetFromVBPtr + VBPtrOffset, + % Debugging logtraceln('~@~Q.', [not(factDerivedClass(DerivedClass, BaseClass, Offset)), reasonDerivedClass_F(DerivedClass, BaseClass, Offset,