-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow CreateInstanceForAnotherGenericParameter to take multi args #45085
Allow CreateInstanceForAnotherGenericParameter to take multi args #45085
Conversation
src/coreclr/src/System.Private.CoreLib/src/System/RuntimeHandles.cs
Outdated
Show resolved
Hide resolved
I can back out the commit 5a6682d and send it as another PR if desired. But this PR seemed like a decent place to put it since I was touching those files anyway. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thanks for fixing this.
Thanks for the review! I'll leave it open for another day or so in case the other reviewers want to chime in. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple misc questions, but otherwise LGTM
Based on a comment at https://github.com/dotnet/runtime/pull/32520/files#r451611457. This PR adds another overload to
CreateInstanceForAnotherGenericParameter
so that the caller can pass 2 parameters instead of just one. I've also hooked it up throughArraySortHelper
so that it avoids the call toRuntimeTypeHandle.Allocate
. This also allows #32520 to cleanly delete theRuntimeTypeHandle.Allocate
method.Also converts the unmanaged side to a QCALL, because why not.
Alternative design
I could introduce a method that takes
params RuntimeType[] genericArgs
. If we did this, it should have a defensive copy in order to guard against mutation (see changes inRuntimeTypeHandle.Instantiate
, also in this PR). I figured that there wasn't a real need to add this just yet since the simplest thing to do for now was to add the 2-param overload. The unmanaged side is already set up now to take as many parameters as needed, so any future changes here can be fully managed.