InMemory: Add translation for object.Equals when object is null #23391
Conversation
Selectively assert exception in tests for other providers which works for InMemory
|
Hello @smitpatel! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
|
Apologies, while this PR appears ready to be merged, I've been configured to only merge when all checks have explicitly passed. The following integrations have not reported any progress on their checks and are blocking auto-merge:
These integrations are possibly never going to report a check, and unblocking auto-merge likely requires a human being to update my configuration to exempt these integrations from requiring a passing check. Give feedback on thisFrom the bot dev teamWe've tried to tune the bot such that it posts a comment like this only when auto-merge is blocked for exceptional, non-intuitive reasons. When the bot's auto-merge capability is properly configured, auto-merge should operate as you would intuitively expect and you should not see any spurious comments. Please reach out to us at fabricbotservices@microsoft.com to provide feedback if you believe you're seeing this comment appear spuriously. Please note that we usually are unable to update your bot configuration on your team's behalf, but we're happy to help you identify your bot admin. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| if (method.Name == nameof(object.Equals)) | ||
| { | ||
| var argument = arguments[0]; | ||
| if (argument.NodeType == ExpressionType.Convert |
There was a problem hiding this comment.
When we are here we are basically matching instance.Equals(param) method.
By default there would be method coming from object, Equals(object), the Type can also add overload of Equals(Type).
Now, we always flow null forward except for parameter values of the a method call since the method may not be take nullable parameters so we convert all the parameter to match their types if they are non-nullable type. Which can happen for the latter overload if any. Since we do this conversion (by calling ConvertToNonNullable function), it would always be a Convert node from nullable to non-nullable value, which we want to remove here since ((bool?)(bool)nullableBoolColumn) == null would throw exception even before comparing to null. Hence I put Convert node. Do you still think we need ConvertChecked here? (This is speculative future proofing), the tests work fine without this if block too.
There was a problem hiding this comment.
In that case let's keep Convert only. Perhaps add a comment in case we decide to sweep thru entire codebase and unify convert+convertchecked checks. But I don't feel strongly.
Selectively assert exception in tests for other providers which works for InMemory