Handle generics in methodimpls for default interface methods#20404
Conversation
The existing logic looking at MethodImpls to find the default interface implementation was not correct in the presence of generics. The MethodImpl record that we build during type load only contain inexact MethodDescs for the declMethod that are not suitable for comparisons. The fix is to pipe through the token and resolve the declaring method from it at the time of dispatch. Fixes #16355.
|
|
||
| // We do CanCastToInterface to also cover variance. | ||
| // We already know this is a method on the same type definition as the (generic) | ||
| // interface but we need to make sure the instantiations match. |
There was a problem hiding this comment.
Variant dispatch is typically done via a two pass technique. Wherein we first iterate to see if there is an exact match, and then a second iteration through the interfaces (of a particular type) to attempt to do a variant dispatch. Looking at the logic in this function, it appears that the variant matching rules here may not be followed, and the variance test cases added do not appear to cover the exact/inexact matching issue.
There was a problem hiding this comment.
The issue of it ignoring variant interface dispatch rules and not doing two passes is orthogonal to the thing I'm fixing here.
I would prefer to track that in a separate issue/pull request for accounting purposes.
|
@dotnet-bot test this please |
|
@dotnet-bot test OSX10.12 x64 Checked Innerloop Build and Test |
|
@dotnet-bot test OSX10.12 x64 Checked Innerloop Build and Test Timed out... |
…coreclr#20404) The existing logic looking at MethodImpls to find the default interface implementation was not correct in the presence of generics. The MethodImpl records we build during type load only contain inexact MethodDescs for the declMethod that are not suitable for comparisons. The fix is to pipe through the token and resolve the declaring method from it at the time of dispatch. Commit migrated from dotnet/coreclr@e95c1f8
2 participants
The existing logic looking at MethodImpls to find the default interface implementation was not correct in the presence of generics. The MethodImpl records we build during type load only contain inexact MethodDescs for the declMethod that are not suitable for comparisons.
The fix is to pipe through the token and resolve the declaring method from it at the time of dispatch.
Fixes #16355.
Fixes #20281.
Fixes #16354.