Roslyn nie mógł skompilować kodu

Po migracji projektu z VS2013 do VS2015 projekt nie jest już kompilowany. Błąd kompilacji występuje w następującej instrukcji LINQ:

static void Main(string[] args)
{
    decimal a, b;
    IEnumerable<dynamic> array = new string[] { "10", "20", "30" };
    var result = (from v in array
                  where decimal.TryParse(v, out a) && decimal.TryParse("15", out b) && a <= b // Error here
                  orderby decimal.Parse(v)
                  select v).ToArray();
}

Kompilator zwraca błąd:

Błąd CS0165 Użycie nieprzypisanej zmiennej lokalnej „b”

Co powoduje ten problem? Czy można to naprawić za pomocą ustawień kompilatora?

Co powoduje ten problem?

Wydaje mi się, że to błąd kompilatora. A przynajmniej tak. Chociaż wyrażenia decimal.TryParse(v, out a)i decimal.TryParse(v, out b)są obliczane dynamicznie, spodziewałem się, że kompilator nadal zrozumie, że zanim dotrze a <= b, oba ai bzostaną ostatecznie przypisane. Nawet z dziwactwami, które możesz wymyślić podczas dynamicznego pisania, spodziewałbym się, że kiedykolwiek ocenię tylko a <= bpo ocenie obu TryParsewywołań.

Jednak okazuje się, że za pośrednictwem operatora i nawrócenia trudne, jest to całkowicie możliwe, aby mieć wyraz A && B && Cktóra ocenia Ai C, ale nie B- Jeśli jesteś przebiegły dość. Zobacz raport o błędzie Roslyn, aby zapoznać się z genialnym przykładem Neala Gaftera.

Wykonanie tej pracy dynamicjest jeszcze trudniejsze - semantyka stosowana, gdy operandy są dynamiczne, jest trudniejsza do opisania, ponieważ aby wykonać rozwiązanie przeciążenia, musisz ocenić operandy, aby dowiedzieć się, jakie typy są zaangażowane, co może być sprzeczne z intuicją. Jednak ponownie Neal wymyślił przykład, który pokazuje, że błąd kompilatora jest wymagany ... to nie jest błąd, to naprawa błędu . Ogromne uznanie dla Neala za udowodnienie tego.

Czy można to naprawić poprzez ustawienia kompilatora?

Nie, ale istnieją alternatywy, które pozwalają uniknąć błędu.

Po pierwsze, możesz zatrzymać dynamikę - jeśli wiesz, że będziesz używać tylko łańcuchów, możesz użyć IEnumerable<string> lub nadać zmiennej zakresu vtyp string(tj from string v in array.). To byłaby moja preferowana opcja.

Jeśli naprawdę chcesz zachować dynamikę, po prostu podaj bwartość na początek:

decimal a, b = 0m;

To nie zaszkodzi - wiemy, że tak naprawdę twoja dynamiczna ocena nie zrobi nic szalonego, więc nadal będziesz przypisywać wartość bprzed jej użyciem, sprawiając, że początkowa wartość będzie nieistotna.

Dodatkowo wydaje się, że dodawanie nawiasów też działa:

where decimal.TryParse(v, out a) && (decimal.TryParse("15", out b) && a <= b)

To zmienia punkt, w którym wyzwalane są różne elementy rozwiązania przeciążenia, i sprawia, że ​​kompilator jest zadowolony.

Pozostaje jeszcze jedna kwestia - zasady specyfikacji dotyczące określonego przypisania do &&operatora muszą zostać wyjaśnione, aby stwierdzić, że mają one zastosowanie tylko wtedy, gdy &&operator jest używany w jego „zwykłej” implementacji z dwoma booloperandami. Spróbuję się upewnić, że zostanie to naprawione dla następnego standardu ECMA.

Wygląda na to, że jest to błąd lub przynajmniej regresja w kompilatorze Roslyn. Zgłoszono następujący błąd, aby go śledzić:

https://github.com/dotnet/roslyn/issues/4509

W międzyczasie doskonała odpowiedź Jona wymaga kilku obejść.

Ponieważ tak ciężko uczył mnie w raporcie o błędzie, spróbuję sam to wyjaśnić.

Wyobraź sobie, że Tjest to typ zdefiniowany przez użytkownika z niejawnym rzutowaniem na boolnaprzemiennie między falsei true, zaczynając od false. O ile kompilator wie, dynamicpierwszy argument do pierwszego &&może mieć wartość tego typu, więc musi być pesymistyczny.

Jeśli więc pozwoli na kompilację kodu, może się to zdarzyć:

• Gdy spinacz dynamiczny ocenia pierwszy &&, wykonuje następujące czynności:
  • Oceń pierwszy argument
  • Jest to T- niejawnie rzut do bool.
  • Och, tak false, więc nie musimy oceniać drugiego argumentu.
  • Wynik &&oceny należy traktować jako pierwszy argument. (Nie, nie false, z jakiegoś powodu.)
• Gdy spinacz dynamiczny ocenia drugi &&, wykonuje następujące czynności:
  • Oceń pierwszy argument.
  • Jest to T- niejawnie rzut do bool.
  • Och, tak true, więc oceń drugi argument.
  • ... O cholera, bnie przydzielono.

Mówiąc konkretnie, w skrócie, istnieją specjalne reguły „określonego przypisania”, które pozwalają nam powiedzieć nie tylko, czy zmienna jest „definitywnie przypisana”, czy „nieprzypisana ostatecznie”, ale także czy jest „zdecydowanie przypisana po falsewyrażeniu” lub „zdecydowanie przypisane po truestwierdzeniu ”.

Istnieją one tak, że podczas pracy z &&i ||(i !i ??i ?:) kompilator może zbadać, czy zmienne mogą być przypisane do poszczególnych gałęzi złożonego wyrażenia boolowskiego.

Jednak działają one tylko wtedy, gdy typy wyrażeń pozostają logiczne . Gdy część wyrażenia jest dynamic(lub nie jest logicznym typem statycznym), nie możemy już wiarygodnie powiedzieć, że wyrażenie to jest truelub false- następnym razem, gdy rzucimy je, boolaby zdecydować, którą gałąź wziąć, mogło zmienić zdanie.

Aktualizacja: to zostało już rozwiązane i udokumentowane :

Określone reguły przypisywania zaimplementowane przez poprzednie kompilatory dla wyrażeń dynamicznych pozwoliły na niektóre przypadki kodu, które mogą spowodować odczytanie zmiennych, które nie są ostatecznie przypisane. Zobacz https://github.com/dotnet/roslyn/issues/4509, aby uzyskać jeden raport na ten temat.

...

Z tego powodu kompilator nie może pozwolić na kompilację tego programu, jeśli val nie ma wartości początkowej. Poprzednie wersje kompilatora (przed VS2015) pozwalały temu programowi na kompilację, nawet jeśli val nie ma wartości początkowej. Roslyn teraz diagnozuje tę próbę odczytania prawdopodobnie niezainicjowanej zmiennej.

To nie jest błąd. Zobacz https://github.com/dotnet/roslyn/issues/4509#issuecomment-130872713, aby zobaczyć przykład, jak dynamiczne wyrażenie tego formularza może pozostawić taką zmienną out nieprzypisaną.