C # derleyicisi bu iç içe geçmiş LINQ sorgusunda neden çıldırıyor?

Aşağıdaki kodu derlemeyi deneyin ve derleyicinin> 3 GB RAM (makinemdeki tüm boş bellek) ve derlemesi çok uzun sürdüğünü (aslında 10 dakika sonra IO istisnası alıyorum) göreceksiniz.

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

Bu tuhaf davranışı kimse açıklayabilir mi?

CS Sürümü: Microsoft (R) Visual C # Derleyici sürüm 4.0.30319.17929
İşletim Sistemi Adı: Microsoft Windows 7 Ultimate
İşletim Sistemi Sürümü: 6.1.7601 Service Pack 1 Build 7601

Bunun tür çıkarımı ve / veya lambda üretimi ile ilgili olduğuna inanıyorum (tür çıkarımının normale ters yönde gitmesi gerektiğinde), aşırı yük çözünürlüğü ile birlikte. Ne yazık ki, sadece tip parametrelerini sağlamak duruma yardımcı olmuyor (muhtemelen hala tip kontrolünü yapmak zorunda olduğu durumda).

Lambdalar analiz edildikten sonra mantıksal olarak sizinkinden eşdeğer kod olması gereken aşağıdaki kod sorunsuz bir şekilde derlenir:

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'in bu tür çıkarımının C # derleyicisinde (bazı problemlerin) derleyiciyi NP-Complete problemini çözmeye zorlayabileceği ve tek gerçek stratejisinin (burada olduğu gibi) kaba kuvvet olduğu yerlerden daha önce yayınladığına inanıyorum. İlgili referansları bulabilirsem buraya ekleyeceğim.

Bulabildiğim en iyi referans, burada Eric'in gerçek maliyete neden olan aşırı yük çözümleme çalışması olduğu gerçeğini tartıştığı yer - hatırlayın, Enumerable.Sum'un lambda / yöntemi kabul eden 10 aşırı yüklemesi var.