The original test didn't reproduce the bug because module C's
%import "import_share_b.i" gave SWIG full knowledge of the
DenseMatrix : public Operator inheritance. When C initialized first,
it added the DenseMatrix->Operator cast to the shared type table.
When B loaded later, the cast already existed so the buggy code
path in swiginit.swg was never reached.
Fix the test by:
- Forward-declaring DenseMatrix in import_share_c.i instead of
%importing import_share_b.i. This makes C register DenseMatrix
as an opaque type without the inheritance cast.
- Changing import order to A, C, B so that C puts DenseMatrix in
the shared table before B tries to add the inheritance cast.
- Adding a proper assertion in the Python runtime test.
- Adding Guile runtime test (guile + schemerunme).
Note: The Guile test fails (reproducing the bug) because Guile uses
SWIG_TypeCheckStruct which compares swig_type_info pointers. The
Python test passes because Python uses SWIG_TypeCheck which compares
type name strings, bypassing the stale pointer issue.