[Mono-bugs] [Bug 74996][Blo] Changed - MI/ method lookup oddness ...

[bugzilla-daemon at bugzilla.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 michael at ximian.com.

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

--- shadow/74996	2005-05-26 13:11:33.000000000 -0400
+++ shadow/74996.tmp.22780	2005-05-27 07:56:44.000000000 -0400
@@ -268,6 +268,56 @@
 (12:59:19) Michael Meeks: it shows the problem precisely,
 (12:59:24) Miguel de Icaza: Ok
 (12:59:41) Michael Meeks: the bug is in mono_class_proxy_vtable - it
 doesn't construct the vtable fully ;-)
 (12:59:52) Michael Meeks: only for 1 level of inheritance beyond the
 basic interfaces it supports,
+
+------- Additional Comments From michael at ximian.com  2005-05-27 07:56 -------
+Ok - still trying to generate a test case - what I do know is this:
+
+* The broken class->interfaces data is coming from:
+
+mono_metadata_interfaces_from_typedef_full (MonoImage *meta, guint32
+index, guint *count, MonoGenericContext *context)
+
+* When you try to reproduce the problem with mono - (source archive
+attached) - you produce a library with a fully qualified parent
+referall structure:
+
+ie. the monodis output on the library is:
+
+  .class interface public auto ansi abstract TestIface
+        implements TestBase6, TestBase2, TestBase1, TestBase3a,
+TestBase3, TestBase5, TestBase4, TestBase7  {
+
+  } // end of class TestIface
+
+This contrasts with the monodis output on the (2nd attachment)
+cli_types_bridgetest.dll dll which has:
+
+.namespace unoidl.test.testtools.bridgetest
+{
+  .class interface public auto ansi abstract XMulti
+        implements unoidl.test.testtools.bridgetest.XMultiBase6,
+unoidl.test.testtools.bridgetest.XMultiBase7  {
+
+  } // end of class unoidl.test.testtools.bridgetest.XMulti
+}
+
+ie. the .dll refers only to the parent types.
+
+Sadly - we can't re-generate the cli_types_bridgetest.dll on Unix /
+using Mono - so you'll just have to believe that this was validly
+created [ got it from a friend ;-].
+
+The code to do that (using reflection.emit) is here:
+
+http://lxr.go-oo.org/udk/cli_ure/source/climaker/climaker_emit.cxx & co.
+
+Needless to say the generated DLL produces usable & useful types on
+Win32. Of course, since mcs produces these fully qualified types - it
+consumes more binary space, and it will (now) still have to pay the
+speed cost of doing that walk; be interesting to know if csc outputs
+that too (one can only assume so). Perhaps it's abug in the .Net
+reflection.emit, or a bug in the emitting code, anyhow ... thankfully
+it wasn't in the proxy method.