#836 Bug in swig runtime/type query system/code generation

[nitro]

For a thorough explanation see here:

http://thread.gmane.org/gmane.comp.programming.swig/10089/focus=10098

-Matthias

[Olly Betts]

Logged In: YES
user_id=14972
Originator: NO

Was this bug fixed by this recent change?

09/05/2007: wuzzeb (John Lenz)
- Change r_ltype in typesys.c to store a hashtable instead of a single value.
several very subtle bugs were being caused by multiple ltypes being mapped
to a single mangled type, mostly when using typedefed template parameters.
Now, r_ltype stores a hashtable of possible ltypes, and when generating the
type table, all the ltypes are added into the swig_type_info structure.

[nitro]

Logged In: YES
user_id=788099
Originator: YES

I can't tell. I'm on a windows machine without all the cygwin/MinGW machinery so I can't check-out SVN and recompile SWIG to test. However if the test code in the link mentioned above works, the problem is probably gone. If you are on the newest SWIG version I'd by happy to put the testcase into a zip file and send it to you.

[Olly Betts]

Logged In: YES
user_id=14972
Originator: NO

I just tried the "main1.i" example from the first message in the gmane thread and get an essentially identical main1_wrap.cxx generated with 1.3.31 and SVN HEAD - in particular, this line is unchanged:

static swig_type_info _swigt__p_YYY = {"_p_YYY", 0, 0, 0, 0, 0};

So I don't think this is fixed.

If that testcase isn't suitable, feel free to attach a better one to this bug.

[nitro]

Logged In: YES
user_id=788099
Originator: YES

Seems like it is not fixed. The testcase is suitable and causes problems in practice. So the reason of this bug is a different one than the one before.
Here I mention a workaround to the problem, but I guess it is not the fix: http://article.gmane.org/gmane.comp.programming.swig/10091 .

Thanks for your efforts!

-Matthias

[John Lenz]

Logged In: YES
user_id=153408
Originator: NO

Ok, I'll take another look at it

[John Lenz]

Logged In: YES
user_id=153408
Originator: NO

Ok, I committed (in r9981) a entry for the test suite. It passes with the latest CVS, and I didn't need to change anything... so you should test again, and if it still doesn't work try modifying Examples/test-suite/multi_import_a.i and so on to get the test suite to fail.

Note, _swigt__p_YYY should be empty, because the dependencies are stored the other way around... _p_XXX has entries for both YYY and ZZZ

[Olly Betts]

The gmane web UI has gone, I dug out the original emails by talking NNTP to the gmane NNTP server by hand taking the group name and article numbr from the URLs above.

The problem can be demonstrated with current git master with this patch to the testcase:

--- a/Examples/test-suite/python/multi_import_runme.py
+++ b/Examples/test-suite/python/multi_import_runme.py
@@ -16,3 +16,7 @@ if z.testx() != 0:
     raise RuntimeError
 if z.testz() != 2:
     raise RuntimeError
+
+print(repr(x))
+print(repr(y))
+print(repr(z))

$ make -s multi_import.multicpptest PY3=1
checking python testcase multi_import (with run test)
<multi_import_b.XXX; proxy of <Swig Object of type 'XXX *' at 0x7f135b218cc0> >
<multi_import_b.YYY; proxy of <Swig Object of type '_p_YYY' at 0x7f135b218fc0> >
<multi_import_a.ZZZ; proxy of <Swig Object of type 'ZZZ *' at 0x7f135b043990> >

Note _p_YYY there.

If the two import statements at the top of that file are switched, then the output is instead YYY *, matching the other two lines.

This is kind of cosmetic - not sure if there are consequences that affect correct behaviour or not, but even if this is the scope of the issue it seems wrong that the import order matters here, and I'd argue the type info should get merged suitably rather than the first entry winning.

[Olly Betts]

Probably related to https://sourceforge.net/p/swig/bugs/1015/