Re: [Swig-devel] Some problems with function hiding (C# new)

[Jan J. <je...@po...>]

Hi everyone,

I have come up with a patch for the issues mentioned previously. There 
is still a warning if you overload a name that has been used as a 
variable in a base class (see A::ccc and B::ccc(int) in the previous 
message) - I am still not sure how to handle this.

The main part of the patch - consisting of modifications to allocate.cxx 
- is here (rev 10739 in my branch):
http://swig.svn.sourceforge.net/viewvc/swig/branches/gsoc2008-jezabek/Source/Modules/allocate.cxx?r1=10418&r2=10739

If you prefer the resulting file then you can find it here:
http://swig.svn.sourceforge.net/viewvc/swig/branches/gsoc2008-jezabek/Source/Modules/allocate.cxx?revision=10739&view=markup

The patch separates the part of function_is_defined_in_bases which was 
responsible for checking if the function is virtual - this part should 
not be sensitive to %ignore and %rename. The remaining part of 
function_is_defined_in_bases only checks the bases that are superclasses 
in the target language (this was not exactly the case earlier - if a 
base class B was ignored but its superclass A was not then a class 
deriving from B could have methods with the 'override' modifier - see 
inherit_same_name4 test-case).

I have tested this change using check-csharp-test-suite; the only 
difference was that the rname testcase stopped complaining about an 
unnecessary 'new' modifier.

I have also created test cases that trigger warnings and errors with the 
previous code - these are revisions 10740 and 10742, available here:
http://swig.svn.sourceforge.net/viewvc/swig?view=rev&revision=10740
http://swig.svn.sourceforge.net/viewvc/swig?view=rev&revision=10742

Finally I have made a minor change to allocate.cxx for finding methods 
that have been overloaded in a subclass (see my first message in this 
thread):
http://swig.svn.sourceforge.net/viewvc/swig?view=rev&revision=10741

All of these changes are still in my branch, but they are not really 
COM-specific (apart of 10741) so I'd be happy to merge them to trunk 
once they are reviewed and accepted as correct.

Thanks,
Jan Jezabek

-- 
My GSoC 2008 development blog: http://jezabekgsoc.wordpress.com/