[Mono-bugs] [Bug 26316][Nor] Changed - ParameterBuilder does not honor custom attributes

[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 lupus@ximian.com.

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

--- shadow/26316	Sat Jun 15 15:32:21 2002
+++ shadow/26316.tmp.22442	Sun Jun 16 12:02:34 2002
@@ -1,16 +1,16 @@
 Bug#: 26316
-Product: Mono/Class Libraries
+Product: Mono/MCS
 Version: unspecified
 OS: other
 OS Details: 
-Status: NEW   
+Status: ASSIGNED   
 Resolution: 
-Severity: 
-Priority: Wishlist
-Component: CORLIB
+Severity: Unknown
+Priority: Normal
+Component: Misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: hestilow@ximian.com               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
 URL: 
 Cc: 
@@ -18,6 +18,25 @@
 
 System.Reflection.Emit.ParameterBuilder keeps custom attributes in a
 private array with no accessors. The array is not used at all outside of
 SetCustomAttributes. This appears to be an inherent limitation of the API,
 but as it is right now this means that "params" arguments are not compiled
 correctly under linux.
+
+------- Additional Comments From lupus@ximian.com  2002-06-16 12:02 -------
+The custom attributes are handled inside metadata/reflection.c when
+the assembly is created.
+This is a mcs bug, IMHO: typemanager.cs:GetConstructor() calls
+FindMembers() to lookup the specific constructor, but it should
+perform the search with the DeclaredOnly binding attr set, so it will
+get only the constructor it searched for and not all the ctor in the
+type hierarchy. Currently it relies on the order of the results since
+it uses the first result and it's nowhere in the spec that I could
+find something that mandates the order.
+With mono the first result happened to be the constructor for
+System.Object (the results are in reverse order), so that is the
+constructor saved in the assembly. Since mcs to handle the params
+keyword is looking for the correct attribute type, it won't work.
+I guess I'll have to reverse the results of FindMembers to avoid code
+that relies on the (undefined) behaviour of the ms runtime such as
+this, but neverless, mcs should be fixed to ask for just the single
+constructor it needs.