[API Proposal]: Add attribute that instructs Reflection to hide target member

[tmat]

Background and motivation

Hot Reload needs to mark metadata entities with an attribute or flag that instructs Reflection to not return them when enumerating types or type members.

See #75154

API Proposal

namespace System.Runtime.CompilerServices;

[AttributeUsage(AttributeTargets.All, AllowMultiple = false, Inherited = false)]
public sealed class MetadataUpdateDeletedAttribute : Attribute;

API Usage

Reflection would filter out all types and members marked with this attribute if any Hot Reload change has been applied to the containing module/type.

Alternative Designs

If we need to optimize more we could mark the deleted member with RTSpecialName flag and only look up the custom attribute for members with this flag.

Risks

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

[aromaa]

Would this be abused to simulate DisablePrivateReflectionAttribute? Could that be a problem?

[jkotas]

Reflection would filter out all types and members marked with this attribute.

Doing an extra custom attribute lookup every time reflection returns something sounds very non-pay-for-play. As proposed, this is guaranteed to introduce performance regressions.

[steveisok]

Doing an extra custom attribute lookup every time reflection returns something sounds very non-pay-for-play. As proposed, this is guaranteed to introduce performance regressions.

Would filtering only if the RuntimeType cache was cleared be sort of pay-for-play?

[jkotas]

Would filtering only if the RuntimeType cache was cleared be sort of pay-for-play?

Enabling the filtering only for modules with EnC delta applies would address the pay-for-play nature.

The other problem is implementation difficulty. There is no single central place where to apply this filtering. Reflection is fetching its data through number of different paths and number of these paths are intertwined with runtime type system where we do not want to apply this filtering. Implementing this for hot-reload would allow us to simplify the implementation by saying that it is best effort that handles the common cases only. Hot reload is not a fully reliable feature by construction, so handling common cases only would follow the theme.

[tmat]

What about the alternative - using flags that are directly in the metadata tables? There would be no custom attribute lookup in that case.

[jkotas]

I think the main pivot is whether this is a proper fully reliable runtime feature or imperfect hot reload only feature.

Proper runtime feature is very expensive to implement. We can look at the using flags for that.

Imperfect hot reload only feature is cheaper to implement. Attribute makes sense for that.

I do not see value in this feature outside of the limited hot reload scenario. DisablePrivateReflectionAttribute that we introduced long time turned out to be useless and it is no longer supported. So imperfect hot reload only feature would make more sense to me.

[tmat]

Imperfect hot reload only feature is cheaper to implement. Attribute makes sense for that.

This would be sufficient imo.

[steveisok]

I think the main pivot is whether this is a proper fully reliable runtime feature or imperfect hot reload only feature.

Proper runtime feature is very expensive to implement. We can look at the using flags for that.

Imperfect hot reload only feature is cheaper to implement. Attribute makes sense for that.

I do not see value in this feature outside of the limited hot reload scenario. DisablePrivateReflectionAttribute that we introduced long time turned out to be useless and it is no longer supported. So imperfect hot reload only feature would make more sense to me.

I see it the same way. Cheapest / most effective place that I can see to pull this off is filter before

runtime/src/coreclr/System.Private.CoreLib/src/System/RuntimeType.CoreCLR.cs

Line 385 in 749340b

return (T[])list;

only if the RuntimeType cache has ever been cleared. No idea the implications - assumption is that hot reload is one of the few (may be the only) consumer that clears the reflection cache.