The problem is that GetIntrinsicIdForMethod operates on MethodDefinition but some parts of HandleCall operate on MethodReference. If the calling code references for example TypeInfo.GetMethods intrinsics detection finds this as being the GetMethods intrinsics but HandleCall doesn't and falls through to the default case which should basically never happen.
The fix is to use MethodDefinition in both places.
Added a test which needed to be done in IL since the last time TypeInfo.GetMethods existed as a method (and not inherited from Type.GetMethods) was in netstandard1.2. So in the IL the call is made to a MethodReference TypeInfo.GetMethods which reproes the problem.
Apps which contain components compiled against netstandard1.2 (or earlier) which call some of the TypeInfo.Get... methods and the app is trimmed will trigger this problem. When it happens it's a fatal error which prevents the app from publishing. Workarounds are only:
Disable trimming of the app - results in a large size impact on the app
Modify the code to either not call TypeInfo.Get... methods or recompile such code to target netstandard2.0 or newer - might not be possible if only compiled binary is available
Risk
Low - the change is only in code related to recognizing Type/TypeInfo.Get... methods and the change is "simple" (instead of operating on the reference, operate on the resolved definition - the resolution happens already anyway, so it will not be triggered by this change).
Testing
Verified that the reported repro for the problem is fixed.
Added a regression test which covers all of the affected TypeInfo.Get... methods.
The problem is that GetIntrinsicIdForMethod operates on MethodDefinition but some parts of HandleCall operate on MethodReference. If the calling code references for example TypeInfo.GetMethods intrinsics detection finds this as being the GetMethods intrinsics but HandleCall doesn't and falls through to the default case which should basically never happen.
The fix is to use MethodDefinition in both places.
Added a test which needed to be done in IL since the last time TypeInfo.GetMethods existed as a method (and not inherited from Type.GetMethods) was in netstandard1.2. So in the IL the call is made to a MethodReference TypeInfo.GetMethods which reproes the problem.
This is a servicing fix for https://github.com/dotnet/linker/issues/3072 into 7.0.
Triage template:
Customer Impact
Apps which contain components compiled against
netstandard1.2
(or earlier) which call some of theTypeInfo.Get...
methods and the app is trimmed will trigger this problem. When it happens it's a fatal error which prevents the app from publishing. Workarounds are only:TypeInfo.Get...
methods or recompile such code to targetnetstandard2.0
or newer - might not be possible if only compiled binary is availableRisk
Low - the change is only in code related to recognizing Type/TypeInfo.Get... methods and the change is "simple" (instead of operating on the reference, operate on the resolved definition - the resolution happens already anyway, so it will not be triggered by this change).
Testing
Verified that the reported repro for the problem is fixed. Added a regression test which covers all of the affected
TypeInfo.Get...
methods.