Skip to content
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

Fix ArgumentOutOfRange in GetConstructor scanning #1621

Merged
merged 1 commit into from
Nov 10, 2020

Conversation

eerhardt
Copy link
Member

With dotnet/runtime#42753, we are adding a new overload to Type.GetConstructor that only takes BindingFlags and Type[].

However, this new overload exposes a bug in the ILLinker where it is using the wrong parameter count to find how many constructor parameters are being used.

Fixing the issue by using the correct parameter count in the switch statement.

@vitek-karas @MichalStrehovsky @marek-safar

With dotnet/runtime#42753, we are adding a new overload to Type.GetConstructor that only takes BindingFlags and Type[].

However, this new overload exposes a bug in the ILLinker where it is using the wrong parameter count to find how many constructor parameters are being used.

Fixing the issue by using the correct parameter count in the switch statement.
Comment on lines +46 to +47
s_typeWithKeptPublicParameterlessConstructor.GetConstructor (BindingFlags.Public, null, Type.EmptyTypes, null);
s_typeWithKeptPublicParameterlessConstructor.GetConstructor (BindingFlags.Public, null, CallingConventions.Any, Type.EmptyTypes, null);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these are new overloads the test is likely to fail on the monolinker.
These should be under #if NETCOREAPP - similar to https://github.com/mono/linker/blob/1ce464d7c9478fda885ec52c05ac6a7602a6274b/test/Mono.Linker.Tests.Cases/Reflection/MethodUsedViaReflection.cs#L90-L117

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is for the existing APIs. It is testing the switch statement for overloads with 4 and 5 parameters, which were in .NET Framework 1.1.

I can't add the new overload in dotnet/runtime because of this ILLinker issue. It is causing my build to fail when I introduce a new GetConstructor overload that only takes 2 parameters because the code is throwing ArgumentOutOfRangeException.

(The reason the new API is being used is because we currently have some internal extension methods on Type that only take the 2 arguments. So the existing code is binding to the new API and not to the extension methods.)

That being said, once I do add the new APIs to net6.0, we can make another PR into mono/linker to support and test for the new overload.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right - sorry I missed that.

@vitek-karas vitek-karas merged commit d8cbe37 into dotnet:master Nov 10, 2020
@eerhardt eerhardt deleted the SupportNewReflectionOverloads branch January 26, 2021 23:36
agocke pushed a commit to dotnet/runtime that referenced this pull request Nov 16, 2022
With #42753, we are adding a new overload to Type.GetConstructor that only takes BindingFlags and Type[].

However, this new overload exposes a bug in the ILLinker where it is using the wrong parameter count to find how many constructor parameters are being used.

Fixing the issue by using the correct parameter count in the switch statement.

Commit migrated from dotnet/linker@d8cbe37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants