Чому компілятор C # божеволіє від цього вкладеного запиту LINQ?

Спробуйте скомпілювати наступний код, і ви побачите, що компілятор займає> 3 ГБ оперативної пам'яті (вся вільна пам'ять на моїй машині) і дуже тривалий час для компіляції (насправді я отримую виняток IO через 10 хвилин).

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 # Compiler версії 4.0.30319.17929
Назва ОС: Microsoft Windows 7 Ultimate
Версія ОС: 6.1.7601 з пакетом оновлень 1, збірка 7601

Я вважаю, що це пов’язано з висновком типу та / або генерацією лямбда-сигналу (коли висновок типу має йти в протилежному напрямку до нормального), у поєднанні з роздільною здатністю перевантаження. На жаль, просто надання параметрів типу не допомагає ситуації (де йому, мабуть, все-таки потрібно виконати перевірку типу).

Наступний код, який логічно повинен бути еквівалентним вашому, після аналізу лямбдас, компілюється без проблем:

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;
}

Я вважаю, що Ерік Ліпперт розміщував до цього висновок про те, що це одне з місць у компіляторі C #, де (певні проблеми) можуть змусити компілятор спробувати вирішити проблему NP-Complete, а його єдиною реальною стратегією (як тут) є груба сила. Якщо я зможу знайти відповідні посилання, я додаю їх тут.

Найкраще посилання, яке я можу знайти, є тут, де Ерік обговорює той факт, що саме робота з вирішення перевантажень спричиняє реальну вартість - пам’ятайте, Enumerable.Sum має 10 перевантажень, які приймають лямбда / метод.