Bug 314209 (MONO56013) - [PATCH] Compiler ignores property accessor names in the metadata
Summary: [PATCH] Compiler ignores property accessor names in the metadata
Status: RESOLVED FIXED
Alias: MONO56013
Product: Mono: Compilers
Classification: Mono
Component: C# (show other bugs)
Version: unspecified
Hardware: Other SuSE 8.1
: P3 - Medium : Enhancement
Target Milestone: ---
Assignee: Martin Baulig
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2004-03-25 00:38 UTC by Patrik Reali
Modified: 2007-09-15 21:24 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
patch (1.25 KB, patch)
2004-03-25 00:39 UTC, Thomas Wiest
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 18:31:36 UTC


---- Reported by reali@acm.org 2004-03-24 17:38:23 MST ----

The mcs compiler has hard-coded property accessors names get_PropertyName 
and set_PropertyName, even if the metadata contains a different name.

The appropriate accessor name must be found in the metadata, not 
constructed. After this modification I'm not sure whether the method 
GetAccessor (in ecore.cs) is used at all, because the MethodInfo will be 
null if the accessor is not visible....

Sadly, I don't know the compiler enough to tell, but please check!

Anyway, the patch is attached.

This change is badly needed by project IIOP.NET (http://iiop-
net.sourceforge.net/), which generates *.dll files from *.idl files and 
uses an hidden property when mapping the CORBA unions.



---- Additional Comments From reali@acm.org 2004-03-24 17:39:05 MST ----

Created an attachment (id=165796)
patch




---- Additional Comments From reali@acm.org 2004-03-25 02:42:22 MST ----

The CLS doesn't require this, but Reflection.Emit allows to build 
such a case.



---- Additional Comments From miguel@ximian.com 2004-03-30 11:40:57 MST ----

Thanks for your patch Patrik, it is now on CVS.



---- Additional Comments From miguel@ximian.com 2004-03-30 19:55:04 MST ----

Reopened the bug, the patch produced a regression on test-169.cs




---- Additional Comments From bmaurer@users.sf.net 2004-04-15 00:19:01 MST ----

So, basically, the problem is that there is no way to say `What is the
base property of this property'. As such, we have 100% half-assed code
to guess the answer to this question. Take a few tough examples:

1) The one above, where the name is not get_xxx. We are not able to do
a query on the methods.
2)

class A {
   public virtual int Foo { get; set; }
}

class B : A {
   public override int Foo { get; }
   static void Main () {
       new B ().Foo = 1;
   }
}

The PropertyInfo for B does not contain the info on the set method, we
have to look it up for the base class

3)

class A {
   public virtual int Foo { get; set; }
}

class B : A {
   private new int Foo { get; }
}

class C : B {
   static void Main () {
       new C ().Foo = 1;
   }
}

The C Foo property can be set in this context. You have to make sure
you are not tricked by the other one.

In all of these cases, we have trouble getting the correct `get' and
`set' method from the propertyinfo. We need a reliable method to do this.

    



---- Additional Comments From bmaurer@users.sf.net 2004-04-15 00:26:04 MST ----

<BenM> btw, you might want to look at the patch Zoltan checked into
reflection.c
<BenM> it is for looking up propinfos
<BenM> we might be able to do something similar, but i did not have
time to study his patch
<miguel> Ok
<miguel> Can you add a reminder?



---- Additional Comments From martin@ximian.com 2004-04-29 19:17:54 MST ----

Fixed in CVS.

Imported an attachment (id=165796)