为什么C＃编译器会对这个嵌套的LINQ查询感到生气？

尝试编译以下代码，您会发现编译器需要> 3 GB的RAM（计算机上的所有可用内存）和很长的时间进行编译（实际上，我在10分钟后得到IO异常）。

using System;
using System.Linq;

public class Test
{
    public static void Main()
    {
        Enumerable.Range(0, 1).Sum(a =>
        Enumerable.Range(0, 1).Sum(b =>
        Enumerable.Range(0, 1).Sum(c =>
        Enumerable.Range(0, 1).Sum(d =>
        Enumerable.Range(0, 1).Sum(e =>
        Enumerable.Range(0, 1).Sum(f =>
        Enumerable.Range(0, 1).Count(g => true)))))));
    }
}

有人可以解释这种奇怪的行为吗？

CS版本：Microsoft（R）Visual C＃编译器版本4.0.30319.17929
操作系统名称：Microsoft Windows 7 Ultimate
操作系统版本：6.1.7601 Service Pack 1 Build 7601

我认为这与类型推断和/或lambda生成（当类型推断必须与正常方向相反）有关，并与重载解析结合在一起。不幸的是，仅提供类型参数并不能解决这种情况（可能仍然需要执行类型检查）。

在分析了lambda之后，以下代码（在逻辑上应与您的代码等效）在编译时不会出现问题：

static void Main()
{
    var x = Enumerable.Range(0, 1).Sum(a);
}

private static int a(int a)
{
    return Enumerable.Range(0, 1).Sum(b);
}
private static int b(int b)
{
    return Enumerable.Range(0, 1).Sum(c);
}
private static int c(int c)
{
    return Enumerable.Range(0, 1).Sum(d);
}
private static int d(int d)
{
    return Enumerable.Range(0, 1).Sum(e);
}
private static int e(int e)
{
    return Enumerable.Range(0, 1).Sum(f);
}
private static int f(int f)
{
    return Enumerable.Range(0, 1).Count(g);
}
private static bool g(int g)
{
    return true;
}

我相信Eric Lippert在C＃编译器中的某些类型之一（某些问题）可能会迫使编译器尝试解决NP-Complete问题之前发布过类型推断，而它的唯一真正策略（如此处）是蛮力的。如果可以找到相关参考，请在此处添加它们。

我可以找到的最佳参考文献是Eric 在这里讨论的事实，这是导致实际成本增加的重载解析工作-请记住，Enumerable.Sum有10个重载接受lambda /方法。