[Mono-bugs] [Bug 52408][Nor] New - MCS does not know the difference between a `new' property and an `override' property

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Wed, 12 May 2004 13:15:13 -0400 (EDT)


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=52408

--- shadow/52408	2004-05-12 13:15:13.000000000 -0400
+++ shadow/52408.tmp.7482	2004-05-12 13:15:13.000000000 -0400
@@ -0,0 +1,140 @@
+Bug#: 52408
+Product: Mono: Compilers
+Version: unspecified
+OS: unknown
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: Unknown
+Priority: Normal
+Component: C#
+AssignedTo: bmaurer@users.sf.net                            
+ReportedBy: bmaurer@users.sf.net               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: MCS does not know the difference between a `new' property and an `override' property
+
+Description of Problem:
+MCS is having trouble with the scoping of properties.
+
+Steps to reproduce the problem:using System;
+
+class A {
+	public int Prop {
+		get { Console.WriteLine (this.GetType ()); return 1; }
+		set { Console.WriteLine (this.GetType ()); }
+	}
+}
+
+class B : A {
+	public int Prop {
+		get { Console.WriteLine (this.GetType ()); return 1; }
+	}
+	
+	static void Main () {
+		B b = new B ();
+		b.Prop ++;
+	}
+}
+
+Actual Results:
+Successful compile
+
+Expected Results:
+It should not compile b.Prop is readonly.
+
+How often does this happen? 
+Always
+
+Additional Information:
+I am not sure how we can tell this from the Metadata, we are not given
+much. The PropertyInfo gives no way for us to tell the new case from the
+override case. I think we have to look *directly* at the MethodInfo.
+
+Miguel?
+
+------- Additional Comments From bmaurer@users.sf.net  2003-12-21 11:17 -------
+Note in the spec, sec 17.6.2 it states:
+
+`When a derived class declares a property by the same name as an
+inherited property, the derived property hides the inherited property
+with respect to both reading and writing.'
+
+It gives an example that we are not able to compile and use correctly:
+
+class A  { public int P { set {...} } } 
+class B: A  { new public int P { get {...} } }
+
+B b = new B();
+b.P = 1; // Error, B.P is read-only
+((A)b).P = 1;  // Ok, reference to A.P
+
+On the line b.P we do not report an error.
+
+
+------- Additional Comments From bmaurer@users.sf.net  2003-12-21 11:50 -------
+Ok, I think I found the critical piece:
+
+class A {
+	public virtual int Prop {
+		get { ... }
+		
+	}
+}
+
+class B : A {
+	public override int Prop {
+		get { ... }
+		set { ... }
+	}
+}
+
+is not valid. Eg, you can not `augment' existing properties. So, what
+we need to do when we are scanning is:
+
+1) Take a look at the PropertyInfo, it will have either a get or a set
+method (or both). If neither of them are `override', then we have
+found the full set of properties
+
+2) If one of them *is* override, we need to search the base classes
+for a definition. 
+
+------- Additional Comments From bmaurer@users.sf.net  2003-12-21 16:40 -------
+Have a patch for the client. Need to do some bug checking on the decl
+side of this (eg, can we run an invalid example, as in my last comment).
+
+------- Additional Comments From bmaurer@users.sf.net  2003-12-22 00:52 -------
+ok, so now i have a patch for everything with properties. Now I have
+to test and work with indexers.
+
+Also, my patch adds .2 sec to bootstrap, I can probably cut down that
+affect.
+
+------- Additional Comments From bmaurer@users.sf.net  2003-12-22 11:19 -------
+Created an attachment (id=6292)
+mcs-52408.patch -- patch
+
+
+------- Additional Comments From bmaurer@users.sf.net  2003-12-22 11:21 -------
+This patch should fix the stuff relating to properties.
+
+I still need to study Indexer calls, however, since that code will
+build on this stuff, I would like to get this checked in first.
+
+I am going to come up with a test suite for this all.
+
+The perf regression is gone, in fact, this patch brings a (very) small
+improvement.
+
+------- Additional Comments From bmaurer@users.sf.net  2003-12-22 12:03 -------
+I just did some regression-prevention patches (issues that I found
+while writing the code, that could easily be reintroduced). Those work
+on the current cvs code, so i checked it in. Will work on the error
+testing later.
+
+------- Additional Comments From miguel@ximian.com  2004-05-12 13:15 -------
+Does it mean that the bug is fixed and its missing tests?
+
+