Add support for generic type argument matchers (It.IsAnyType and custom matchers)

[stakx]

These commits add support for generic type argument matching. 😎

For starters, the only built-in type matcher is It.IsAnyType:

mock.Setup(m => m.Method<It.IsAnyType>(...))...

Creating a custom type matcher:

The type matcher infrastructure is designed to be fully extensible:

class Exceptions : ITypeMatcher
{
    public bool Matches(Type typeArgument) => typeof(Exception).IsAssignableFrom(typeArgument);
}

handler.Setup(h => h.Handle<Exceptions>())
       .Callback(() => Console.WriteLine("Handled an exception.");

This allows matchers to satisfy generic type contraints:

public interface IJuggler
{
    void Juggle<TBall>() where TBall : Ball
}

class AnyBall : Ball, ITypeMatcher
{
    public bool Matches(Type typeArgument) => true;
}

new Mock<IJuggler>().Setup(j => j.Juggle<AnyBall>())...;

When the type is constrained to something that won't allow you to implement ITypeMatcher, there's [TypeMatcher]:

public interface IRedirector
{
    void Redirect<TDelegate>(TDelegate handler) where TDelegate : Delegate;
}

[TypeMatcher(typeof(It.IsAnyType))]
public delegate void AnyDelegate();

var redirector = new Mock<IRedirector>();
redirector.Setup(r => r.Redirect<AnyDelegate>(...)))...

Accessing the type arguments in Callback and Returns:

(@michal-ciechan, this one is for you: You requested that some "invocation context" be injected into Callback and Returns callbacks, it turns out Moq already has a suitable type for that: IInvocation.)

In order for Callback and Returns to be able to know which type arguments were used, there are two new overloads that accept a InvocationAction and InvocationFunc, respectively:

public interface IFactory
{
    T Create<T>();
}

var factory = new Mock<IFactory>();
factory.Setup(f => f.Create<It.IsAnyType>())
       .Returns(new InvocationFunc(invocation =>
                {
                    var type = invocation.Method.GetGenericTypeArguments()[0];
                    return Activator.CreateInstance(type);
                });

var something = factory.Object.Create<Something>();

These two types are designed as delegate type look-alikes, however they aren't actually delegates. This was necessary to prevent the C# compiler from starting to pick the wrong Callback and Returns overloads in everyday use cases.

Matching arguments of a generic type:

interface IFrobbler
{
    void Frobble<T>(T arg);
}

var frobbler = new Mock<IFrobbler>();
frobbler.Setup(f => f.Frobble(It.IsAny<It.IsAnyType>()))
        .Callback((object arg) => ...);

Things left to do:

• Add support for It.IsAny<It.IsAnyType>. Or, more generally speaking: It.IsAny<TTypeMatcher>, It.IsNotNull<TTypeMatcher>, etc.

• If some or all of the above is implemented, add tests for the Capture code paths. (More specifically, I am worrying about the type conversions (T) hidden inside the Match class. Those will generally fail when T is a type matcher.)

  Update: This is only partially fulfilled. While Capture.* shouldn't throw, CaptureMatch<T> won't work just yet. This is left as a TODO for another time.

• Add support for composite types making use of type matchers, e.g. It.IsAnyType?, It.IsAnyType[], It.IsAnyType[,], IEnumerable<It.IsAnyType>, ref/in/out It.IsAnyType, etc. Same for custom matcher types. It's possible that this cannot be made to work with custom argument matchers.

  Update: While that would be great, it would also negatively affect performance as every type parameter would have to be decomposed just to discover whether it includes a type matcher. For now, we're going the opposite direction and try to make type matcher discovery as fast as possible.

Closes #343.

/cc @michal-ciechan, @oddbear, @kzu

[stakx]

Since this loop is going to run for every generic method Moq encounters, it might be a good idea to cache information about whether or not some Type is a type matcher.

[stakx]

This might be useful in MockDefaultValueProvider, too. Today, DefaultValue.Mock will simply attempt to mock types even if they don't have a default constructor, resulting in a DynamicProxy exception (which could be hidden).

An alternative would be to instead add a type.HasDefaultConstructor() check inside type.IsMockable(). That way, MockDefaultValueProvider would no longer attempt to mock default ctor-less types and delegate to DefaultValue.Empty.

[michal-ciechan]

Nice! Thanks for caring about this issue so long after! Will take a look at the code and take it out for a spin tomorrow!

[stakx]

It just occurred to me that we could special-case It.IsAny<It.IsAnyType>() to be roughly equivalent to @helloserve's It.Ignore() (see #790). Some thoughts regarding this idea:

• Since It.IsAny gets used a lot, perhaps we should require that all type matchers carry a [TypeMatcher] attribute so that they can be identified more quickly.

• Consider special-casing other built-on matchers, too, where that makes sense.

• What to do about custom argument matchers? Those would have to deal with It.IsAnyType et al. themselves.

• Ideally, argument matchers wouldn't support just It.IsAnyType, but any type matcher.

• It.IsAnyType should be declared as a struct so that It.IsAny<It.IsAnyType?> could work as well if one wants to explictly include null values.
  (Edit: Not necessarily. It's likely we'll at some point need to add more standard type matchers such as It.IsAnyClass and It.IsAnyStruct to account for the most common generic type constraints. So whether It.IsAnyType is declared as a class or struct probably ought to depend on which generic type constraint is more common in general practice.)