Menu
▾
▴
Re: [Swig-devel] Test suite regressions since 1.3.27
|
From: Marcelo M. <mm...@ac...> - 2005-12-23 01:18:51
|
I see the problem with the operator(), hmms, gcc-3.4.5 is happy, but
the code is wrong...
I'll try to fix it today.
Marcelo
William S Fulton wrote:
> Marcelo Matus wrote:
>
>> William S Fulton wrote:
>>
>>> I've been looking at the test-suite for the first time since 1.3.27
>>> was released. There are some regressions which I've shown below. Do
>>> any of them look familiar?
>>>
>>> I noticed that templates of a typedef'd type no longer generate code
>>> using the original type, rather it resolves the typedef in the
>>> wrapper code. Usually the original type gets generated. The change
>>> might have something to do with the C# vector<Real> breakage in
>>> li_std_vector.
>>
>>
>>
>> yes, there were a couple of broken template cases when not resolving
>> the typedef, and following
>> the docs:
>>
>> """
>> <p>
>> Since the type system knows how to handle <tt>typedef</tt>, it is
>> generally not necessary to instantiate different versions of a template
>> for typenames that are equivalent. For instance, consider this code:
>> </p>
>>
>> <div class="code">
>> <pre>
>> %template(intList) vector<int>;
>> typedef int Integer;
>> ...
>> void foo(vector<Integer> *x);
>> </pre>
>> </div>
>>
>> <p>
>> In this case, <tt>vector<Integer></tt> is exactly the same type as
>> <tt>vector<int></tt>. Any use of
>> <tt>Vector<Integer></tt> is mapped back to the
>> instantiation of <tt>vector<int></tt> created earlier.
>> Therefore, it is
>> not necessary to instantiate a new class for the type
>> <tt>Integer</tt> (doing so is
>> redundant and will simply result in code bloat).
>> </p>
>>
>> """
>>
>> now there are more replacements of the original type. Note, however,
>> that in cases as
>>
>> template <class Type>
>> class Vector {
>> typedef Type *iterator;
>> iterator begin();
>> }
>>
>> %extend Vector {
>> %typename(out) iterator {...}
>> }
>>
>> %template(Vd) Vector<double>;
>>
>> the implicit 'typedef double *iterator' is not followed and the
>> proper typemap
>> is generated.
>>
>>
>>>
>>> Some of the type wrapper classes have changed name (descriptor
>>> names). Usually when a template is involved - is this intentional?
>>> The side effect is that these C#/Java classes have different names
>>> which a user must recode for. Some people use these type wrapper
>>> classes, but not everyone though. Eg, in template_default.i, the
>>> name was
>>> SWIGTYPE_p_std__vectorTdouble_t, now it is called
>>> SWIGTYPE_p_std__vector_Tdouble_t.
>>
>>
>>
>> no, there is no intentional change in there, but it looks like a
>> 'split' of the type, mangle
>> both parts by separate, and then concatenate them in one, instead of
>> mangling the entite type
>> at once. I'll take a look.
>>
>>>
>>> The wrong exceptions are also being thrown in many places, but I can
>>> probably track that one down easily. The other changes I'm not sure
>>> without having a good look.
>>>
>>> William
>>>
>>
>> hmm, the 'namespace_class.i' case compiles fine here in csharp, what
>> compiler
>> are you using? (g++ 3.4.5 here).
>>
>>> Checking testcase namespace_class under csharp
>>> namespace_class_wrap.cxx: In function `void
>>> CSharp_EulerT3D_callint(void*,
>>> void*)':
>>> namespace_class_wrap.cxx:877: error: `operator()' not defined
>>> namespace_class_wrap.cxx: In function `void
>>> CSharp_EulerT3D_lessint(void*,
>>> void*)':
>>> namespace_class_wrap.cxx:892: error: `operator<' not defined
>>> namespace_class_wrap.cxx: In function `void
>>> CSharp_EulerT3D_callfooi(void*,
>>> void*)':
>>> namespace_class_wrap.cxx:907: error: `operator()' not defined
>>> namespace_class_wrap.cxx: In function `void
>>> CSharp_EulerT3D_lessfooi(void*,
>>> void*)':
>>> namespace_class_wrap.cxx:922: error: `operator<' not defined
>>> make[2]: *** [csharp_cpp] Error 1
>>> make[1]: *** [namespace_class.cpptest] Error 2
>>> Checking testcase typemap_namespace under csharp
>>> ../../../../Examples/test-suite/typemap_namespace.i:31: Error: Can't
>>> copy typemap.
>>> make[2]: *** [csharp_cpp] Error 1
>>> make[1]: *** [typemap_namespace.cpptest] Error 2
>>> Checking testcase li_std_except under csharp
>>> ../../../../Examples/test-suite/li_std_except.i:8: Warning(401):
>>> Nothing known about base class 'std::exception'. Ignored.
>>> Checking testcase li_std_vector (with run test) under csharp
>>> ./li_std_vector_runme.cs(510) error CS1502: The best overloaded
>>> match for method 'li_std_vectorNamespace.li_std_vector.half(
>>> li_std_vectorNamespace.SWIGTYPE_p_std__vector_Tfloat_t)' has some
>>> invalid arguments
>>> ./li_std_vector_runme.cs(510) error CS1503: Argument 1: Cannot
>>> convert from 'li_std_vectorNamespace.RealVector' to '
>>> li_std_vectorNamespace.SWIGTYPE_p_std__vector_Tfloat_t'
>>> ./li_std_vector_runme.cs(510) error CS1501: No overload for method
>>> `half' takes `1' arguments
>>> Compilation failed: 3 error(s), 0 warnings
>>> make[2]: *** [csharp_compile] Error 1
>>> make[1]: *** [li_std_vector.cpptest] Error 2
>>>
>>>
>> yes, the next one is an error in java, note that there is a new test
>>
>> vmethod(Bar b);
>>
>> ie, the virtual method receives a 'by value' instance. pointers
>> and referecences work fine.
>>
>>
>>> Checking testcase director_basic (with run test) under java
>>> director_basic_wrap.cxx: In member function `virtual Bar
>>> SwigDirector_MyClass::vmethod(Bar)':
>>> director_basic_wrap.cxx:745: error: no match for 'operator!' in '!argp'
>>> director_basic_wrap.cxx:745: error: candidates are: operator!(bool)
>>> <built-in>
>>> make[2]: *** [java_cpp] Error 1
>>> make[1]: *** [director_basic.cpptest] Error 2
>>> Checking testcase namespace_class under java
>>> namespace_class_wrap.cxx: In function `void
>>> Java_namespace_1class_namespace_1classJNI_EulerT3D_1callint(JNIEnv*,
>>> _jclass*, long long int, long long int)':
>>> namespace_class_wrap.cxx:892: error: `operator()' not defined
>>> namespace_class_wrap.cxx: In function `void
>>> Java_namespace_1class_namespace_1classJNI_EulerT3D_1lessint(JNIEnv*,
>>> _jclass*, long long int, long long int)':
>>> namespace_class_wrap.cxx:909: error: `operator<' not defined
>>> namespace_class_wrap.cxx: In function `void
>>>
>>> Java_namespace_1class_namespace_1classJNI_EulerT3D_1callfooi(JNIEnv*,
>>> _jclass*, long long int, long long int)':
>>> namespace_class_wrap.cxx:926: error: `operator()' not defined
>>> namespace_class_wrap.cxx: In function `void
>>>
>>> Java_namespace_1class_namespace_1classJNI_EulerT3D_1lessfooi(JNIEnv*,
>>> _jclass*, long long int, long long int)':
>>> namespace_class_wrap.cxx:943: error: `operator<' not defined
>>> make[2]: *** [java_cpp] Error 1
>>> make[1]: *** [namespace_class.cpptest] Error 2
>>> Checking testcase li_std_except under java
>>> ../../../../Examples/test-suite/li_std_except.i:8: Warning(401):
>>> Nothing known about base class 'std::exception'. Ignored.
>>>
>
> compiler is gcc-3.3.5. I've fixed the exception problems now.
>
> With regard to the templates and typedefs, it seems that
>
> %template(VectInt) vector<Integer>;
>
> is now illegal and will produce bad code, whereas before it worked. I
> agree that there is no point in having two %templates for typedef'd
> typemaps, but surely the user can declare the %template either using
> or not using the typedef'd type? So surely either one of the following
> is allowable:
>
> %template(VectInt) vector<Integer>;
> %template(VectInt) vector<int>;
>
> Maybe a warning should be declared if both are attempted?
>
> I'll look at the new pass by value director test another day now.
>
> William
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Swig-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-devel
|