Fix broken comparison of the generic methods - #990
Conversation
Argument matchers for generic methods failed to tell apart two distinct overloads that share a name but differ by their generic method definition (e.g. a base interface method and a `new` reimplementation in a derived interface with a narrower generic constraint). CanCompareGenericMethods identified generic overloads by name only, so a specification built for the base overload was considered comparable to a call on the derived overload. Combined with the assignability check on the closed generic arguments, a base-typed matcher (Arg.Any<IOutBase>) would match a call to the derived overload closed over a subtype (IOutDerived), producing false matches when verifying calls and resolving return values. Compare the generic method definitions instead of the names. This still allows a single method to match calls closed over different (assignable) type arguments, while keeping genuinely distinct overloads apart. Fixes nsubstitute#828 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a regression scenario alongside the nsubstitute#828 field report: overriding a generic method (as opposed to 'new' hiding it) keeps a single method slot, so the spec and the recorded call resolve to the same generic method definition whether the substitute is used through the derived or the base type. This ensures comparing generic method definitions does not tighten matching too far for legitimate overrides. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@zvirja happy for me to release current main as 6.2.0? Should i set up the nuget-push environment to require a reviewer prior to it running? |
|
I am creating 2 more PRs and we could go after that.
I am not sure I follow what you mean and exactly it happens. But I would say - no, if one creates a tag, we assume one knows what they are doing, so it's okay :) |
|
Something like this: 
You seem to be forgetting I am still involved with this project and have access to create tags 😅 🤣 I take your point though; definitely less friction to just tie it to releases, I just tend to be (overly?) cautious with this stuff. 😄 |
Wow, I didn't even know you could review those things 😮 So many projects I work alone on, so nice to learn 😅
I wouldn't be much worried. Worst case scenario - we can always unlist things and bump versions to fix. I had to fix the mess so many times in my life until now, so I wouldn't worry at all. But of course we shall be reasonable in our actions 😅 |
|
@dtchepak Let's proceed with merge once me merge |
2 participants
Fixes #828
Currently we compare generic methods by names which is wrong in case we e.g. have shadowing via
new. Do proper generic definition comparison, so that we preserve methods identity. Added tests to validate the scenarios.