[Mono-bugs] [Bug 81850][Wis] New - gmcs/CSC and System.Reflection(.Emit) differences between Mono, .NET

[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 jonpryor at vt.edu.

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

--- shadow/81850	2007-06-10 15:40:21.000000000 -0400
+++ shadow/81850.tmp.26455	2007-06-10 15:40:21.000000000 -0400
@@ -0,0 +1,142 @@
+Bug#: 81850
+Product: Mono: Compilers
+Version: unspecified
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Wishlist
+Component: C#
+AssignedTo: rharinath at novell.com                            
+ReportedBy: jonpryor at vt.edu               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: gmcs/CSC and System.Reflection(.Emit) differences between Mono, .NET
+
+Please fill in this template when reporting a bug, unless you know what you
+are doing.
+Description of Problem:
+
+There are two sets of differences in the names generated for
+explicitly-implemented methods and properties between gmcs 1.2.x and CSC.EXE:
+
+1. Property names generated by gmcs are missing a namespace.
+
+2. Generic method names use [[FullyQualifedTypeName]] instead of
+<TypeName>.  (For added humor, property names use <TypeName>, as CSC does,
+but property names still lack the namespace name, as specified in (1)).
+
+The second issue is a fairly recent development, having started in Mono
+1.2.x.  Mono 1.1.18.1 (included with openSUSE 10.2) follows CSC behavior.
+
+Steps to reproduce the problem:
+1. Compile the attached `demo.cs' in gmcs, CSC.EXE 2.0.
+2. Compare the names generated for generic explicitly-implemented interface
+methods and properties.  For your convenience, the gmcs-generated IL is
+attached as demo-gmcs.il, and the CSC-generated IL is attached as demo-csc.il.
+3. Profit!
+
+Actual Results:
+
+For a property name, gmcs 1.2.4 (/trunk/ r78869) generates:
+
+  .property object IEnumerator.Current()
+  {
+    .get instance object Foo::System.Collections.IEnumerator.get_Current()
+  } // end of property Foo::IEnumerator.Current
+  .property class Foo 'IEnumerator<Foo>.Current'()
+  {
+    .get instance class Foo
+Foo::'System.Collections.Generic.IEnumerator`1[[Foo, test, Version=0.0.0.0,
+Culture=neutral, PublicKeyToken=null]].get_Current'()
+  } // end of property Foo::'IEnumerator<Foo>.Current'
+
+Note that the names lacks a namespace; compare with CSC, in which the
+namespace is present:
+
+  .property instance object System.Collections.IEnumerator.Current()
+  {
+    .get instance object Foo::System.Collections.IEnumerator.get_Current()
+  } // end of property Foo::System.Collections.IEnumerator.Current
+  .property instance class Foo
+'System.Collections.Generic.IEnumerator<Foo>.Current'()
+  {
+    .get instance class Foo
+Foo::'System.Collections.Generic.IEnumerator<Foo>.get_Current'()
+  } // end of property
+Foo::'System.Collections.Generic.IEnumerator<Foo>.Current'
+
+Further, note that the above generic properties use <TypeName>.  Compare to
+the following explicitly-implemented interface *methods*; gmcs:
+
+  .method private hidebysig newslot virtual final
+          instance class
+[mscorlib]System.Collections.Generic.IEnumerator`1<class Foo>
+          'System.Collections.Generic.IEnumerable`1[[Foo, test,
+Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]].GetEnumerator'()
+cil managed
+  {
+    .override  method instance class
+[mscorlib]System.Collections.Generic.IEnumerator`1<!0> class
+[mscorlib]System.Collections.Generic.IEnumerable`1<class Foo>::GetEnumerator()
+    // Code size       2 (0x2)
+    .maxstack  8
+    IL_0000:  ldnull
+    IL_0001:  ret
+  } // end of method Foo::'System.Collections.Generic.IEnumerable`1[[Foo,
+test, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]].GetEnumerator'
+
+CSC:
+
+  .method private hidebysig newslot virtual final
+          instance class
+[mscorlib]System.Collections.Generic.IEnumerator`1<class Foo>
+          'System.Collections.Generic.IEnumerable<Foo>.GetEnumerator'() cil
+managed
+  {
+    .override  method instance class
+[mscorlib]System.Collections.Generic.IEnumerator`1<!0> class
+[mscorlib]System.Collections.Generic.IEnumerable`1<class Foo>::GetEnumerator()
+    // Code size       7 (0x7)
+    .maxstack  1
+    .locals init (class
+[mscorlib]System.Collections.Generic.IEnumerator`1<class Foo> V_0)
+    IL_0000:  nop
+    IL_0001:  ldnull
+    IL_0002:  stloc.0
+    IL_0003:  br.s       IL_0005
+
+    IL_0005:  ldloc.0
+    IL_0006:  ret
+  } // end of method
+Foo::'System.Collections.Generic.IEnumerable<Foo>.GetEnumerator'
+
+Expected Results:
+
+Ideally, CSC behavior would be followed for both properties and methods.
+
+At minimum, one would think that property names and method names would be
+_consistent_ with each other (at present they aren't).
+
+How often does this happen? 
+
+Always.
+
+Additional Information:
+
+I stumbled across this while trying to add explicit-interface
+implementation support to monodocer.  With monodocer, we lookup a member
+name from the XML and use this name with
+System.Type.GetMember(string,BindingFlags).  Furthermore, I'm trying to use
+the CSC names within the XML files, because (1) I'd like to import from the
+ECMA documentation, which uses CSC-style names, and (2) they're sane (shorter).
+
+Unfortunately, with the current gmcs "name-mangling" scheme for
+explicitly-implemented interfaces, I can't go from XML-string -> MemberInfo
+directly; instead, I'll need to iterate over all members on the type, do a
+MemberInfo -> XML-string conversion, and then compare.  Yay overhead! 
+(Fortunately this *only* needs to be done for explicitly-implemented
+interface members, which are fairly rare.)