Method setup broken when specifying the same parameters in a different order in setup

[adamreeve]

Code to reproduce:

using Moq;
using Xunit;

public class MoqTest
{
    [Fact]
    public void MoqWorks()
    {
        var a = new MyClass();
        var b = new MyClass();
        var mock = new Mock<IDoStuff<MyClass>>();
        mock.Setup(m => m.DoStuff(a, b)).Returns(1);
        mock.Setup(m => m.DoStuff(b, a)).Returns(1);
        Assert.Equal(1, mock.Object.DoStuff(a, b));
        Assert.Equal(1, mock.Object.DoStuff(b, a));
    }

    public interface IDoStuff<in T>
    {
        int DoStuff(T a, T b);
    }

    public class MyClass { }
}

Both asserts should pass but one fails as DoStuff returns the default value of 0.

This was tested with Moq version 4.2.1510.2205.

[adamreeve]

This isn't dependent on having a generic interface, this simplified test case also shows the same issue:

using Moq;
using Xunit;

public class MoqTest
{
    [Fact]
    public void MoqWorks()
    {
        var a = new MyClass();
        var b = new MyClass();
        var mock = new Mock<IDoStuff>();
        mock.Setup(m => m.DoStuff(a, b)).Returns(1);
        mock.Setup(m => m.DoStuff(b, a)).Returns(1);
        Assert.Equal(1, mock.Object.DoStuff(a, b));
        Assert.Equal(1, mock.Object.DoStuff(b, a));
    }

    public interface IDoStuff
    {
        int DoStuff(MyClass a, MyClass b);
    }

    public class MyClass { }
}

It does seem related to the type of the arguments though, using ints doesn't show this problem, this test passes:

using Moq;
using Xunit;

public class MoqTest
{
    [Fact]
    public void MoqWorks()
    {
        const int a = 99;
        const int b = 123;
        var mock = new Mock<IDoStuff>();
        mock.Setup(m => m.DoStuff(a, b)).Returns(1);
        mock.Setup(m => m.DoStuff(b, a)).Returns(1);
        Assert.Equal(1, mock.Object.DoStuff(a, b));
        Assert.Equal(1, mock.Object.DoStuff(b, a));
    }

    public interface IDoStuff
    {
        int DoStuff(int a, int b);
    }
}

Strings also work, so it's not a reference type vs value type issue, but could be related to those types implementing IEquatable?

[LeonidLevin]

This has to do with how hash code is calculated for ExpressionKey objects.
I am working on it now.

[adamreeve]

Great, thanks for fixing this @LeonidLevin!