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

Keep InvocationShape argument matchers & expressions in sync #793

Merged
merged 4 commits into from
Apr 1, 2019

Conversation

stakx
Copy link
Contributor

@stakx stakx commented Apr 1, 2019

Fixes #711. See explanation in #711 (comment) as well as in commit messages for details.

The previous commit's test fails because during invocation-to-setup
matching, an argument expression gets re-evaluated that wouldn't have
to be re-evaluated; it has previously been associated with a constant
matcher.

Looking more closely at `MatcherFactory` it becomes obvious that arg-
ument matchers are in some cases derived from partially evaluated ex-
pressions; but those never make it back into the setup expression and
therefore end up "disagreeing" with their associated matchers.

Note that this bugfix adds yet another layer of complexity to matcher
types by letting `MatcherFactory` return `Pair<,>` instances. It would
perhaps be better to simply let `IMatcher`s carry the `Expression`
from which they were derived, however that ends up being a more com-
plicated refactoring mostly due to `Match` and `ParamArrayMatcher`.
Let's do that another time.
@stakx stakx added this to the 4.11.0 milestone Apr 1, 2019
src/Moq/MatcherFactory.cs Outdated Show resolved Hide resolved
src/Moq/Matchers/ParamArrayMatcher.cs Outdated Show resolved Hide resolved
`MatcherFactory.CreateMatcher` has been refactored in a earlier commit
to return expressions that are in sync with the created matchers; ex-
cept for `ParamArrayMatcher`.
@stakx stakx changed the title InvocationShape's argument matchers & expressions shouldn't go out of sync Keep InvocationShape argument matchers & expressions in sync Apr 1, 2019
@stakx stakx merged commit 0aa9574 into devlooped:master Apr 1, 2019
@stakx stakx deleted the issue-711 branch April 1, 2019 23:15
Copy link
Contributor Author

@stakx stakx left a comment

Choose a reason for hiding this comment

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

Some TODOs for future PRs.

/// example, while <see langword="int"/> is assignable-to <see langword="object"/>, you
/// will need a conversion in a LINQ expression tree to model the value-type boxing operation.
/// </remarks>
internal static Expression ConvertIfNeeded(this Expression expression, Type type)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

  • Check whether this method can be reused in ActionObserver, which currently has its own (but slightly different) logic for doing the same thing.

  • Also, add a set of tests that test our assumptions (stated here informally inside <remarks>) about when Convert nodes are necessary.

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.

None yet

1 participant