Bugzilla – Bug 313436
[PATCH] Scope problem when overriding private method in nested type
Last modified: 2007-09-15 21:24:23 UTC
---- Reported by bmaurer@users.sf.net 2003-12-22 16:00:05 MST ---- This should not compile: using System; class A { public virtual int Blah () { return 1; } } class B : A { new int Blah () { return 0; } class C : B { public override int Blah () { return 2; } static void Main () { Console.WriteLine (new C ().Blah ()); } } } B.Blah is closer to C.Blah than A.Blah is. We are ignoring it because we just ignore the private methods. On csc you get: t.cs(14,23): error CS0506: 'B.C.Blah()' : cannot override inherited member 'B.Blah()' because it is not marked virtual, abstract, or override t.cs(10,10): (Location of symbol related to previous error) t.cs(14,23): error CS0507: 'B.C.Blah()': cannot change access modifiers when overriding 'private' inherited member 'B.Blah()'t.cs(10,10): (Location of symbol related to previous error) ---- Additional Comments From bmaurer@users.sf.net 2003-12-22 16:07:34 MST ---- Related: We compile using System; class A { public virtual int Blah () { return 1; } } class B : A { new public static int Blah () { return 0; } class C : B { public override int Blah () { return 2; } static void Main () { Console.WriteLine (new C ().Blah ()); } } } csc gives t.cs(12) error CS0506: `B.C.Blah': cannot override inherited member `B.Blah' because it is not virtual, abstract or override ---- Additional Comments From bmaurer@users.sf.net 2003-12-22 17:04:41 MST ---- wrt to the origional issue, it looks like csc is not respecting the spec: "For the purposes of locating the overridden base method, a method is considered accessible if it is public, if it is protected, if it is protected internal, or if it is internal and declared in the same program as C." This says nothing about private and nested types. However, this statement is a departure from the normal accessibility rules, so we should go with csc, I think. On the other one, it is crystal clear: "The overridden base method is a virtual, abstract, or override method. In other words, the overridden base method cannot be static or non-virtual." wrt the second problem, the spec is quite clear: ---- Additional Comments From bmaurer@users.sf.net 2003-12-23 00:45:30 MST ---- Created an attachment (id=165372) Patchedy patch patch ---- Additional Comments From bmaurer@users.sf.net 2003-12-23 00:47:39 MST ---- This patch should clear up these two issues at least, they make the scoping stuff alot cleaner. Also gives a pretty nice perf boost. I get .5 s improvement on corlib. ---- Additional Comments From bmaurer@users.sf.net 2003-12-23 12:28:19 MST ---- Created an attachment (id=165373) Ignore the last version of this patch it is fscked ---- Additional Comments From bmaurer@users.sf.net 2004-02-27 22:56:39 MST ---- Created an attachment (id=165374) An updated patch ---- Additional Comments From bmaurer@users.sf.net 2004-02-27 23:01:46 MST ---- Ok, small update to this patch to account for changes in cvs. Marcus reports a *huge* boost in QT# compile times -- 28s to 20s. Miguel, can you look at the patch + comment. ---- Additional Comments From bmaurer@users.sf.net 2004-02-28 14:20:18 MST ---- Created an attachment (id=165375) Documentified ---- Additional Comments From bmaurer@users.sf.net 2004-02-28 14:22:52 MST ---- Change log: 1) Added FindMethodToOverride which finds the overriden method using the membercache rather than the slower lookup system 2) Clean up MemberSignature comparing stuff, so it doesnt do boxing (now called more because of ^) 3) Avoid type lookups when checking for dup methods ---- Additional Comments From bmaurer@users.sf.net 2004-02-29 16:06:32 MST ---- Ok, here is a full change log (not the first part, because miguel applied that): class.cs, decl.cs: Add a method FindMethodToOverride for looking up the base for overriding methods. The reason we have this is two fold. First, we are able to use the MemberCache here, which gains us alot of speed as compared to the lookup system. The second reason is that the spec has some different visibility requirements for overrideing. For example, the following is not valid: class A { public virtual int Blah () { return 1; } } class B : A { new int Blah () { return 0; } class C : B { public override int Blah () { return 2; } static void Main () { Console.WriteLine (new C ().Blah ()); } } } CSC gives t.cs(14,23): error CS0506: 'B.C.Blah()' : cannot override inherited member 'B.Blah()' because it is not marked virtual, abstract, or override t.cs(10,10): (Location of symbol related to previous error) t.cs(14,23): error CS0507: 'B.C.Blah()': cannot change access modifiers when overriding 'private' inherited member 'B.Blah()'t.cs(10,10): (Location of symbol related to previous error) CSC does not follow the spec to the letter here. Before, we were following the spec, however, this makes us follow CSC's behavior. See https://bugzilla.novell.com/show_bug.cgi?id=MONO52458 for details. ---- Additional Comments From bmaurer@users.sf.net 2004-02-29 16:08:48 MST ---- Created an attachment (id=165376) Update ---- Additional Comments From bmaurer@users.sf.net 2004-02-29 16:16:54 MST ---- Created an attachment (id=165377) More comments ---- Additional Comments From bmaurer@users.sf.net 2004-03-16 18:27:04 MST ---- Created an attachment (id=165378) cleanify ---- Additional Comments From bmaurer@users.sf.net 2004-03-17 11:12:43 MST ---- So you dont forget ;-). ---- Additional Comments From bmaurer@users.sf.net 2004-03-17 17:53:27 MST ---- Created an attachment (id=165379) hopefully the last time :-) ---- Additional Comments From bmaurer@users.sf.net 2004-03-17 21:16:27 MST ---- In cvs (finally ;-). Imported an attachment (id=165372) Imported an attachment (id=165373) Imported an attachment (id=165374) Imported an attachment (id=165375) Imported an attachment (id=165376) Imported an attachment (id=165377) Imported an attachment (id=165378) Imported an attachment (id=165379) Unknown operating system unknown. Setting to default OS "Other".