[Swig-devel] [ swig-Bugs-3416818 ] Wrong Ruby class for C++ subclass with same name as base

[SourceForge.net <no...@so...>]

Bugs item #3416818, was opened at 2011-10-01 07:24
Message generated for change (Comment added) made by wsfulton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3416818&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: ruby
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Robin Stocker (niborvisions)
>Assigned to: William Fulton (wsfulton)
Summary: Wrong Ruby class for C++ subclass with same name as base

Initial Comment:
When wrapping a C++ class hierarchy using two Ruby modules, and the subclass has the same name as the base class but is in a different namespace, the Ruby class information is wrong at runtime. The situation (shortened):

module base.i:
  class Foo::Bar;

module sub.i:
  class Foo::Sub::Bar;
  Foo::Bar *bar();
  Foo::Sub::Bar *subbar();

Now, when calling bar() from Ruby, the Ruby class of the returned object is Foo::Sub::Bar, where instead it should be Foo::Bar. The class of subbar() is Foo::Sub::Bar (which is correct):

bar: Foo::Sub::Bar
subbar: Foo::Sub::Bar

What's interesting is that the __swigtype__ is correct:

bar: _p_Foo__Bar
subbar: _p_Foo__Sub__Bar

When debugging with gdb, I can see that the entries in swig_types point to the same clientdata struct. So, I assume that somewhere the clientdata is set wrongly.

What's also interesting is that, with -DSWIGRUNTIME_DEBUG, the following cast list is printed for bar (I would expect _p_Foo__Bar to be the first cast in the list here):

SWIG_InitializeModule: type 0 _p_Foo__Bar
SWIG_InitializeModule: cast type _p_Foo__Sub__Bar
SWIG_InitializeModule: cast type _p_Foo__Bar

When changing the class name of Foo::Sub::Bar to Baz, the problem goes away.

Please extract the attached example, build and run it to reproduce the problem.

The version of SWIG is svn trunk 12817.

----------------------------------------------------------------------

>Comment By: William Fulton (wsfulton)
Date: 2011-11-13 09:11

Message:
Fixed for swig-2.0.5, thanks for the patch in #3421876.

----------------------------------------------------------------------

Comment By: Robin Stocker (niborvisions)
Date: 2011-10-19 09:13

Message:
Created a patch in the patch tracker to fix this, see:

http://sourceforge.net/tracker/?func=detail&aid=3421876&group_id=1645&atid=301645

----------------------------------------------------------------------

Comment By: Robin Stocker (niborvisions)
Date: 2011-10-08 09:29

Message:
By the way, is there a reason the variable needs to be global at all? I see
that it was changed in r6944:

-    Printv(klass->header, "\nswig_class c", valid_name, ";\n", NIL);
+    Printv(f_wrappers, "swig_class c", valid_name, ";\n\n", NIL);


----------------------------------------------------------------------

Comment By: Robin Stocker (niborvisions)
Date: 2011-10-08 09:16

Message:
I found the source of the problem!

In the generated code, in base_wrap.cxx, there's this variable
declaration:
  swig_class SwigClassBar;

In sub_wrap.cxx, there's the same declaration:
  swig_class SwigClassBar;

So this is actually the same variable at runtime, and when assigning
"SwigClassBar.klass" during module loading, the later assignment wins, thus
leading to Foo::Sub::Bar.

Renaming the second variable to SwigClassSubBar, or making the variables
static solves the problem. I'll try to prepare a patch.

----------------------------------------------------------------------

Comment By: Robin Stocker (niborvisions)
Date: 2011-10-01 07:27

Message:
The example is also available here:

https://github.com/robinst/swig-ruby-subclass-namespace-problem

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3416818&group_id=1645