[Mono-bugs] [Bug 21255] Changed - CS527 error incorrectly reported + segfault

[bugzilla-daemon@rocky.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by miguel@ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=21255

--- shadow/21255	Tue Mar  5 16:06:10 2002
+++ shadow/21255.tmp.1115	Tue Mar  5 20:15:07 2002
@@ -1,22 +1,21 @@
 Bug#: 21255
 Product: Mono/Class Libraries
 Version: unspecified
 OS: other
 OS Details: 
-Status: NEW   
-Resolution: 
+Status: RESOLVED   
+Resolution: FIXED
 Severity: Unknown
 Priority: Normal
 Component: CORLIB
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: mkestner@speakeasy.net               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
 URL: 
-Cc: 
 Summary: CS527 error incorrectly reported + segfault
 
 Description of Problem: 
 mcs built on win32 from CVS update at approx 12:00 AM 3/1/02
 mono on linux built from CVS update at approx 12:00 AM 3/2/02
 
@@ -115,7 +114,31 @@
 Well, this is also a bug in Windows anyways.  The problem is that we
 only look for implementation methods that are being defined by the
 current class.  It did not occur to me that the implementation might
 be on a parent.
 
 I will start working on this now.
+
+
+------- Additional Comments From miguel@ximian.com  2002-03-05 20:15 -------
+OK, on the C# end of things, this turned out to be a nasty little
+"feature" of the runtime and the compiler.  
+
+The attached program will compile with some bizarre flags to allow the
+`look in my parent for an interface method implementation' (hidebysig,
+ewslot, virtual, final).  Otherwise this hack does not work.
+
+Now, this is tricky, because if nobody ever implements the interface,
+the flags are completely different *IN THE BASE METHOD*.
+
+So this sounded fishy.  I split up the code in two: the interface and
+the base class from the class that inherits the class and implements
+the interface.
+
+And surprise: to work around this problem, they do create an explicit
+implementation that proxies the call to the original caller.  So this
+is more inneficient than the plain call.
+
+Since I can not change the method definition once I have created the
+MethodBuilder without major changes to the compiler, I will just keep
+the proxy code in place.