Add Type.GetMemberWithSameMetadataDefinitionAs #53704

eerhardt · 2021-06-03T23:46:41Z

This method allows for trim-compatible reflection over generic types. Developers can cache the open-generic MemberInfo statically, and then using the closed-generic Type, they can look up the corresponding MemberInfo. This results in a hard reference to the generic member, so the trimmer won't remove it or warn about the reflection usage.

Fix #45771

…type definition Fix dotnet#45771

* Fix a bug for NestedType * Use new method libraries that were working around not having it

dotnet-issue-labeler · 2021-06-03T23:46:44Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

jkotas · 2021-06-04T00:21:00Z

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

+                MemberTypes.Property => GetPropertyWithSameMetadataDefinitionAs(member),
+                MemberTypes.Field => GetFieldWithSameMetadataDefinitionAs(member),
+                MemberTypes.Event => GetEventWithSameMetadataDefinitionAs(member),
+                MemberTypes.NestedType => GetNestedTypeWithSameMetadataDefinitionAs(member),


Is this going to do anything interesting for nested types? The nested types are not instantiated using the enclosed type instantiation, so I think this will always return the same type as that was passed in.

It probably isn't going to do anything interesting, but I thought it would be incomplete without it, since GetMembers returns the nested types.

The nested types are not instantiated using the enclosed type instantiation,

I learned that the hard way in my tests 😄

runtime/src/libraries/System.Reflection/tests/TypeInfoTests.cs

Lines 1581 to 1584 in 7a15f97

if (openGenericMember is not Type)

{

Assert.True(closedGenericMember.DeclaringType == closedGenericType, $"'{closedGenericMember.Name}' doesn't have the right DeclaringType");

}

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

…tadataDefinitionAs

jkotas · 2021-06-09T23:37:49Z

....Runtime.InteropServices.JavaScript/src/System/Runtime/InteropServices/JavaScript/Runtime.cs

-                return result;
+                return (MethodInfo)taskType.GetMemberWithSameMetadataDefinitionAs(s_taskGetResultMethodInfo);
+            }
+            catch (ArgumentException)


Would it be better to keep the original code? Is throwing and catching exception here going to be a performance problem?

The caught exception should be rare - cases where you are returning a Task that isn't t.GetType() == typeof(Task) and isn't Task<T> or a derived type.

I'm not sure if just doing the try is going to be performance problem. This code is about interop'ing with JavaScript, which itself is fairly expensive.

I can revert and use the original code. But it is a pity that this was the first scenario discovered and the one written up in the API issue, and we decide that we can't use this API for this scenario.

Other options I've thought about:

Trying to check if the type is Task<T> or a derived type before calling GetMemberWithSameMetadataDefinitionAs, but I'm not sure how to do this efficiently and without walking the base types manually.

Reverting back to GetMemberWithSameMetadataDefinitionAs returning null if it isn't found. We wouldn't need to do anything special here then.

I think probably the best option in the short term is to just leave this code as it is in main. We can always change it later.

Thoughts?

It seems like we keep dancing around the scenario of "I have a Task (or something that derives from it), and I want to get its result, and I'm ok with boxing." This seems like it should be fairly straightforward: put a first-class API on Task or TaskExtensions to provide this information. For Task, it could return null. Involving reflection for this scenario seems awfully heavyweight.

What is Task or TaskExtensions going to do differently? It will have to use reflection to do the job. (Or it will have to be non-pay-for-play.)

without walking the base types manually.

Walking the base types manually would be like 5 lines and pretty efficient.

I am not sure whether the exceptional case is as rare as you may think - we have multiple types inheriting from Task in the framework itself. If it is really rare here, the try/catch should be ok.

It is interesting that the caller uses Array.Empty<object>() for results that are Task exactly, but this logic returns null for results that derive from Task. It suggests that the results that derive from Task may be broken. Have you actually seen a test case that hits the type deriving from Task, but not from Task<T> case?

That's the non-pay-for-play concern. If we were to decide we're fine with the cost, then the approach we've previously discussed is similar to what you outline, e.g.

public async Task<object?> AsObjectTask() { await this.ConfigureAwait(false); return this is ITaskWithResult t ? t.ResultAsObject : null; }

so implementation is obviously far from hard. Not sure exactly what you'd want to call it, or whether it'd be better hidden away somewhere as a static (non-extension) method. Yes, this has been requested now and again, but it's not all that common a need.

Fair enough. I saw 13 matches for typeof(Task<>) in source.dot.net and believed this to be a more common pattern. (To be fair, I didn't trace back many of those calls.) If this isn't as common as I thought, no worries. :)

For my edification, how do you search for typeof(Task<>) in source.dot.net? Or do you mean find all Task<TResult> usage via source.dot.net and then using the browser's search look for typeof(Task?

https://source.dot.net/System.Private.CoreLib/R/5ca7b77f3df89fc6.html

Because the matches in the left pane show the reference in context (the entire source line is there), you can CTRL-F in your browser and search "typeof(Task<>)". Kinda hokey, but if it works, it works.

Thanks. Quickly skimmed the results I see:

Most of them are checking to see whether a type is a Task or Task<> in order to decide whether the method should be considered async / is task returning.

Another large chunk are various forms of code generators trying to determine what return type to use for the generated method (e.g. CodeDOM, F#'s conversion from tasks to its async model)

Some are looking to understand the type of the T in the Task<T> as part of API exploration / doc generation.

A few are trying to match up the T to see which of a few known types it might map to, e.g. for razor page handler execution

1, from Microsoft.JSInterop, was about getting the object result from an arbitrary Task<T>

src/libraries/System.Private.CoreLib/src/System/Type.cs

src/libraries/System.Private.CoreLib/src/Resources/Strings.resx

GrabYourPitchforks · 2021-06-10T00:11:48Z

....Runtime.InteropServices.JavaScript/src/System/Runtime/InteropServices/JavaScript/Runtime.cs

-                return result;
+                return (MethodInfo)taskType.GetMemberWithSameMetadataDefinitionAs(s_taskGetResultMethodInfo);
+            }
+            catch (ArgumentException)


It seems like we keep dancing around the scenario of "I have a Task (or something that derives from it), and I want to get its result, and I'm ok with boxing." This seems like it should be fairly straightforward: put a first-class API on Task or TaskExtensions to provide this information. For Task, it could return null. Involving reflection for this scenario seems awfully heavyweight.

eerhardt · 2021-06-10T23:40:13Z

I believe this is ready for final review. PTAL.

src/mono/System.Private.CoreLib/src/System/RuntimeType.Mono.cs

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

ghost · 2021-06-11T22:39:01Z

Tagging @dotnet/area-system-reflection for review.

jkotas

LGTM

ghost · 2021-06-15T19:03:11Z

Hello @eerhardt!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.

eerhardt added 3 commits June 3, 2021 10:57

Add API to find MethodInfo on instantiated generic type from generic …

0e13c8a

…type definition Fix dotnet#45771

* Rename to GetMemberWithSameMetadataDefinitionAs

5cce652

* Fix a bug for NestedType * Use new method libraries that were working around not having it

Implement GetMemberWithSameMetadataDefinitionAs in mono

7a15f97

dotnet-issue-labeler bot added area-System.Reflection new-api-needs-documentation labels Jun 3, 2021

jkotas reviewed Jun 4, 2021

View reviewed changes

stephentoub reviewed Jun 4, 2021

View reviewed changes

src/coreclr/System.Private.CoreLib/src/System/RuntimeType.CoreCLR.cs Outdated Show resolved Hide resolved

Respond to PR feedback

0936408

eerhardt marked this pull request as ready for review June 4, 2021 23:14

eerhardt requested a review from marek-safar as a code owner June 4, 2021 23:14

eerhardt requested a review from GrabYourPitchforks June 4, 2021 23:15

Fix trimming warning

f80df3e

marek-safar approved these changes Jun 7, 2021

View reviewed changes

eerhardt added 3 commits June 7, 2021 09:14

Merge remote-tracking branch 'upstream/main' into GetMemberWithSameMe…

db0d2f9

…tadataDefinitionAs

Merge remote-tracking branch 'upstream/main' into GetMemberWithSameMe…

4011013

…tadataDefinitionAs

Fix wasm tests

9f09790

jkotas reviewed Jun 9, 2021

View reviewed changes

GrabYourPitchforks reviewed Jun 9, 2021

View reviewed changes

src/libraries/System.Private.CoreLib/src/System/Type.cs Show resolved Hide resolved

GrabYourPitchforks reviewed Jun 10, 2021

View reviewed changes

eerhardt added 2 commits June 9, 2021 22:10

Revert JavaScript Runtime changes.

f775458

Revert whitespace changes caused by VS

a38c660

eerhardt force-pushed the GetMemberWithSameMetadataDefinitionAs branch from a1ca1c2 to a38c660 Compare June 10, 2021 03:10

Support inheritance in GetMemberWithSameMetadataDefinitionAs.

5fe95b0

jkotas reviewed Jun 11, 2021

View reviewed changes

src/mono/System.Private.CoreLib/src/System/RuntimeType.Mono.cs Show resolved Hide resolved

jkotas reviewed Jun 11, 2021

View reviewed changes

src/coreclr/System.Private.CoreLib/src/System/RuntimeType.CoreCLR.cs Show resolved Hide resolved

jeffhandley added area-System.Reflection and removed area-System.Reflection labels Jun 11, 2021

Respond to PR feedback

4a0e0f8

jkotas approved these changes Jun 15, 2021

View reviewed changes

eerhardt added the auto-merge label Jun 15, 2021

eerhardt merged commit cf7e7a4 into dotnet:main Jun 15, 2021

eerhardt deleted the GetMemberWithSameMetadataDefinitionAs branch June 15, 2021 21:14

jkotas mentioned this pull request Jun 16, 2021

Implement GetMethodWithSameMetadataDefinitionAs for NativeAOT dotnet/runtimelab#1249

Closed

ghost locked as resolved and limited conversation to collaborators Jul 15, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Type.GetMemberWithSameMetadataDefinitionAs #53704

Add Type.GetMemberWithSameMetadataDefinitionAs #53704

eerhardt commented Jun 3, 2021

dotnet-issue-labeler bot commented Jun 3, 2021

jkotas Jun 4, 2021

eerhardt Jun 4, 2021

jkotas Jun 9, 2021

eerhardt Jun 10, 2021

GrabYourPitchforks Jun 10, 2021

jkotas Jun 10, 2021 •

edited

Loading

jkotas Jun 10, 2021 •

edited

Loading

stephentoub Jun 11, 2021 •

edited

Loading

GrabYourPitchforks Jun 11, 2021

stephentoub Jun 11, 2021 •

edited

Loading

GrabYourPitchforks Jun 11, 2021

stephentoub Jun 11, 2021 •

edited

Loading

GrabYourPitchforks Jun 10, 2021

eerhardt commented Jun 10, 2021

ghost commented Jun 11, 2021

jkotas left a comment

ghost commented Jun 15, 2021

	if (openGenericMember is not Type)
	{
	Assert.True(closedGenericMember.DeclaringType == closedGenericType, $"'{closedGenericMember.Name}' doesn't have the right DeclaringType");
	}

Add Type.GetMemberWithSameMetadataDefinitionAs #53704

Add Type.GetMemberWithSameMetadataDefinitionAs #53704

Conversation

eerhardt commented Jun 3, 2021

dotnet-issue-labeler bot commented Jun 3, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkotas Jun 10, 2021 • edited Loading

Choose a reason for hiding this comment

jkotas Jun 10, 2021 • edited Loading

Choose a reason for hiding this comment

stephentoub Jun 11, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephentoub Jun 11, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephentoub Jun 11, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eerhardt commented Jun 10, 2021

ghost commented Jun 11, 2021

jkotas left a comment

Choose a reason for hiding this comment

ghost commented Jun 15, 2021

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

jkotas Jun 10, 2021 •

edited

Loading

jkotas Jun 10, 2021 •

edited

Loading

stephentoub Jun 11, 2021 •

edited

Loading

stephentoub Jun 11, 2021 •

edited

Loading

stephentoub Jun 11, 2021 •

edited

Loading

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (`@msftbot`) and give me an instruction to get started! Learn more here.