Expression that takes a DateTimeOffset causes Visual Studio Internal Compiler Error

Question

I was trying to mock an interface which takes a DateTimeOffset? as one of its parameters. All of a sudden, Visual Studio started reporting an 'Internal Compiler Error' and that it has 'stopped working'. After a lot of trials, I started removing files one by one, and then code line by line. This reduced to the below code, which reproduces this error:

public class testClass
{
    public interface ITest
    {
        void Test(DateTimeOffset? date);
    }

    public void test2()
    {
        var mock = new Mock<ITest>();
        mock.Setup(x => x.Test(new DateTime(2012, 1, 1)));
    }
}

The issue seems to be the line :

mock.Setup(x => x.Test(new DateTime(2012, 1, 1)));

If I comment it, the compiler works fine. Also, the issues is that I am setting up a new DateTime(), which fits in a DateTimeOffset.

Is this a bug in Moq, or VS2012? Anyone ever got this error before?

UPDATE

The following code sample also results in a compile error, both with the regular Visual Studio 2012 compiler and with Roslyn CTP September 2012:

using System;
using System.Linq.Expressions;

public interface ITest
{
    void Test(DateTimeOffset? date);
}

public class TestClass
{
    Expression<Action<ITest>> t = x => x.Test(new DateTime(2012, 1, 1));
}

The error:

1>CSC : error CS0583: Internal Compiler Error (0xc0000005 at address 00D77AFB): likely culprit is 'BIND'.

This code has nothing to do with Moq.

Answer 1

It is clearly a bug in the semantic analyzer. (The text "likely culprit is BIND" is characteristic of bugs in the semantic analyzer, which is called the "binder" internally.) The scenario here is that we have a lifted-to-nullable user-defined conversion in a lambda that is being converted to an expression tree. That code was a bug farm. I thought I wrote a test case for this exact scenario, but maybe I didn't.

In any event, the problem is likely my bad, so sorry about that. Not much I can do about it now though.

What is truly bizarre though is that the bug allegedly repros on both Roslyn and the C# 5 compiler. That is a crazy coincidence, because the Roslyn and C# 5 compilers have completely different code for this part of the semantic analysis. We rewrote most of it from scratch. Strange that we'd get it wrong in the same way twice.

Anyway, Kevin will see this since you tagged it Roslyn, and if you want to enter a bug on the Connect site, that would be appreciated by the team I'm sure.

UPDATE:

Wait, you got the exact same error in Roslyn? Then what is happening is probably that the IDE is still using the C# 5 analysis library. If you write code that loads the offending code into a Roslyn compilation and analyzes it, you likely will not get the error. Right?