System.Reflection.CustomAttributeFormatException thrown on a retrieval of derived attribute with overridden property getter

[pedrobsaila]

Fixes #110412
Fixes #119490

Sorry for the delay, I've been busy these last weeks

[AaronRobinsonMSFT]

LGTM, thank you!

@MichalStrehovsky Any further feedback?

[MichalStrehovsky]

@MichalStrehovsky Any further feedback?

If we really want this, it looks reasonable. For posterity though, this is implementing some of C# language semantics into the runtime reflection stack (the runtime reflection stack doesn't consider property inheritance in general, like I pointed out in #110945 (comment), or how Type.InvokeMember(BindingFlags.SetProperty) works).

IL is more expressible than what C# allows. C# can sometimes get into IL-level corner cases due to NuGet versioning and compile-time seeing different things than runtime.

What is implemented here will allow things like:

[Derived(Prop = 123)]
class Program;

class BaseAttribute : Attribute
{
    public virtual int Prop { get; set; }
}

class DerivedAttribute : BaseAttribute
{
    // Note `new` keyword
    public new virtual int Prop { get => base.Prop; }
}

to work even though the C# compiler would not accept this.

Hopefully this is sufficiently leafy within the reflection stack that it won't affect many things. I'm not worried about this breaking existing apps (because we're just fixing a throw to not throw). However there's is an aspect that if someone does take advantage of this not throwing, they may run into new issues that we didn't consider.

Like I wrote in #110945 (comment) this needed a bit more design discussion to consider these things before we decide whether we really want to fix this.

[jeffhandley]

@AaronRobinsonMSFT -- I defer to you on this with @MichalStrehovsky's input. I'll assign to you to drive it to closure or merge. Thanks!

[AaronRobinsonMSFT]

@pedrobsaila I've made some edits on a fork of your branch here. @jkotas helped bring me up to speed on the concerns that @MichalStrehovsky was expressing. I hadn't fully appreciated the issues that this represented. My branch has the following changes:

• Walk the Attribute heirarchy and look for the first setter. Simpler fix for System.Reflection.CustomAttributeFormatException thrown on a retrieval of derived attribute with overridden property getter #110412. Justification: Creating overrides of properties is an oddity for attributes and trying to handle that potentially complex policy in the Reflection stack in't helpful.
• Covariance isn't supported for overridding Attribute property types (see Overriden property in a custom attribute crashes runtime #119490). We shouldn't crash, but we can throw an exception.

Please let me know if you're willing to fold in the changes I've made or handle them yourself. Appreciate your work here and want to ensure you are acknowledged for your effort.

[pedrobsaila]

Hey @AaronRobinsonMSFT yes you can fold in your changes, no worries about that.

[AaronRobinsonMSFT]

Hey @AaronRobinsonMSFT yes you can fold in your changes, no worries about that.

@pedrobsaila I don't think I can push to your branch. I can create a PR from my branch or you can cherry-pick my changes, up to you.

[AaronRobinsonMSFT]

/ba-g Known issues.

Issues fixed in #125051

[AaronRobinsonMSFT]

@MichalStrehovsky Please take another look at this. I've narrowed the scenario considerably.