Fix ConstructorInfo.GetGenericArguments to return empty array#128059
Merged
steveisok merged 6 commits intoMay 13, 2026
Conversation
Constructors are never generic methods in the CLR (there is no IL or language support for generic constructors). Previously, calling GetGenericArguments() on a ConstructorInfo threw NotSupportedException because the call fell through to the base MethodBase implementation, which throws by design when not overridden. RuntimeMethodInfo returns an empty array for non-generic methods, but RuntimeConstructorInfo did not override the method and so threw. Add a single override on the abstract ConstructorInfo base so the fix applies uniformly to all subclasses (CoreCLR, Mono, NativeAOT, MetadataLoadContext, custom ConstructorInfo subclasses, etc.). Fixes dotnet#128041 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
Tagging subscribers to this area: @steveisok, @dotnet/area-system-reflection |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR changes ConstructorInfo.GetGenericArguments() to return an empty Type[] instead of falling back to MethodBase.GetGenericArguments() (which throws). This makes constructors behave like other non-generic methods when queried for generic arguments.
Changes:
- Override
ConstructorInfo.GetGenericArguments()inSystem.Private.CoreLibto always return an empty array. - Add a regression test asserting
ConstructorInfo.GetGenericArguments()is empty for constructors on both non-generic and generic types.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/libraries/System.Private.CoreLib/src/System/Reflection/ConstructorInfo.cs | Adds ConstructorInfo.GetGenericArguments() override returning an empty array for all constructors. |
| src/libraries/System.Runtime/tests/System.Reflection.Tests/ConstructorInfoTests.cs | Adds xUnit coverage ensuring constructors’ GetGenericArguments() returns an empty array across representative types. |
Open
3 tasks
NativeAOT previously overrode ConstructorInfo.GetGenericArguments() to throw NotSupportedException for desktop compat. Remove that override so the new ConstructorInfo base implementation (returns empty array) is used uniformly. Update two tests that asserted the prior throw behavior to assert the new empty-array contract: - System.Reflection.Context CustomConstructorInfo test - System.Reflection.MetadataLoadContext invariant test (TestConstructorInfoCommonInvariants is the upstream of several failing tests in TypeTests and ConstructorTests) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
This is a breaking change that would need settled before merging. |
3 tasks
The System.Reflection.MetadataLoadContext tests target both NetCoreAppCurrent and NetFrameworkCurrent. On .NET Framework, ConstructorInfo.GetGenericArguments() still throws NotSupportedException (this fix only ships in .NET Core). Guard the invariant check with #if NET so the test asserts the appropriate behavior on each runtime. This addresses the remaining failures in the Libraries_NET481 leg: TestConstructors1, TestInvariantCode, TestMakeArray, TestInvariants, TestMakeGenericType, and TestMakeMdArray (all upstream-rooted in TestConstructorInfoCommonInvariants). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Per @max-charlamb's suggestion, add coverage for an open generic type (GenericClassWithConstructor<>) in addition to the closed one. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
max-charlamb
approved these changes
May 12, 2026
jkotas
reviewed
May 12, 2026
jkotas
reviewed
May 12, 2026
Per @jkotas's review, the public override on a public type needs to be declared in the reference assembly so it appears in the public API surface area. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Per @jkotas's review, the ConstructorInfo base class already defines MemberType => MemberTypes.Constructor (and exposes it in the reference assembly), so the override on RuntimeConstructorInfo.CoreCLR is unnecessary. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
jkotas
approved these changes
May 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Constructors are never generic methods in the CLR (there is no IL or language support for generic constructors). Previously, calling GetGenericArguments() on a ConstructorInfo threw NotSupportedException because the call fell through to the base MethodBase implementation, which throws by design when not overridden.
RuntimeMethodInfo returns an empty array for non-generic methods, but RuntimeConstructorInfo did not override the method and so threw. Add a single override on the abstract ConstructorInfo base so the fix applies uniformly to all subclasses (CoreCLR, Mono, NativeAOT, MetadataLoadContext, custom ConstructorInfo subclasses, etc.).
Fixes #128041