Parameterize Matcher::matches
and Matcher::explain_match
.
#369
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note: I've created this PR for now just to check that the changes below fully pass CI.
This allows the use of smart pointers for the actual value when invoking
Matcher::matches
andMatcher::explain_match
. The Protobuf implementation namely uses a kind of smart pointer. The lifetime on that smart pointer has no a priori relation to that of the parameteractual
, causing the borrow checker to complain whenever invoking an inner matcher on the output ofas_view
.This commit addresses the problem by allowing the
ViewProxy
-- rather than a reference to it -- to be passed directly toMatcher::matches
andMatcher::explain_match
. It does this by making those two methods generic with respect to the input type. They must only implementDeref<Target = Self::ActualT>
.The new test
googletest/tests/arena_test.rs
illustrates this with a simplified example.Introducing these generics unfortunately makes
Matcher
no longer object-safe. Since several matchers construct trait objts onMatcher
, this also introduces an internal-only wrapper traitObjectSafeMatcher
which everyMatcher
auto-implements.While this makes some changes to how
Matcher
is defined and implemented, it should have no effect on how it is used, other than to fix the aforementioned problem. So it should not affect compatibility for most users of the crate.Fixes #323.