Roslyn kodu derleyemedi

Question 1

Projemi VS2013'ten VS2015'e taşıdıktan sonra proje artık oluşturulmuyor. Aşağıdaki LINQ deyiminde bir derleme hatası oluşur:

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

Derleyici bir hata döndürür:

Hata CS0165 Atanmamış yerel değişken 'b' kullanımı

Bu soruna ne sebep olur? Bir derleyici ayarıyla düzeltmek mümkün mü?

Question 2

Bu soruna ne sebep olur?

Bana bir derleyici hatası gibi görünüyor. En azından yaptı. Her ne kadar decimal.TryParse(v, out a)ve decimal.TryParse(v, out b)ifadeler dinamik değerlendirilir, ben beklenen derleyici hala anlamak için o ulaştığında a <= b, hem ave bkesinlikle atanır. Dinamik yazmada karşılaşabileceğiniz tuhaflıklara rağmen, yalnızca her a <= biki TryParsearamayı da değerlendirdikten sonra değerlendirmeyi bekliyorum .

Ancak, operatör ve zor dönüşüm yoluyla, bir ifadeye sahip tamamen mümkün olduğunu çıkıyor A && B && Cki değerlendirir Ave Cancak Beğer sen kurnaz yeterli -. Neal Gafter'ın ustaca örneği için Roslyn hata raporuna bakın .

Bunu yapmak dynamicdaha da zor - işlenenler dinamik olduğunda dahil olan anlambilimin açıklanması daha zordur, çünkü aşırı yük çözümlemesini gerçekleştirmek için hangi türlerin dahil olduğunu bulmak için işlenenleri değerlendirmeniz gerekir, bu da sezgiye aykırı olabilir. Ancak yine Neal, derleyici hatasının gerekli olduğunu gösteren bir örnek buldu ... bu bir hata değil, bir hata düzeltmesi . Bunu kanıtladığı için Neal'a büyük miktarda övgü

Derleyici ayarları aracılığıyla düzeltmek mümkün mü?

Hayır, ancak hatayı engelleyen alternatifler var.

İlk olarak, dinamik olmasını engelleyebilirsiniz - eğer sadece dizeleri kullanacağınızı biliyorsanız, o zaman aralık değişkenini kullanabilir IEnumerable<string> veyav bir tür string(ie from string v in array) verebilirsiniz . Bu benim tercih ettiğim seçenek olurdu.

Eğer varsa gerçekten o dinamik tutmak için gereken, sadece vermek bbaşlangıç için bir değer:

decimal a, b = 0m;

Bunun herhangi bir zararı olmayacak - aslında dinamik değerlendirmenizin çılgınca bir şey yapmayacağını biliyoruz, bu yüzden bonu kullanmadan önce bir değer atayarak başlangıç değerini geçersiz kılacaksınız.

Ek olarak, parantez eklemek de işe yarıyor gibi görünüyor:

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

Bu, çeşitli aşırı yük çözümleme parçalarının tetiklendiği noktayı değiştirir ve derleyiciyi mutlu eder.

Hala bir sorun var - &&operatörle kesin atamayla ilgili spesifikasyon kurallarının, yalnızca &&operatör iki boolişlenenle "normal" uygulamasında kullanıldığında geçerli olduklarını belirtmek için açıklığa kavuşturulması gerekir . Bunun bir sonraki ECMA standardı için düzeltildiğinden emin olmaya çalışacağım.

Question 3

Bu, Roslyn derleyicisinde bir hata veya en azından bir gerileme gibi görünüyor. Takip etmek için aşağıdaki hata dosyalandı:

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

Bu arada, Jon'un mükemmel cevabının birkaç çözümü var.

Question 4

Hata raporunda çok okula gittiğim için, bunu kendim açıklamaya çalışacağım.

Imagine T, ve ile başlayarak ve boolarasında değişen örtük bir tür olan kullanıcı tanımlı bir türdür . Derleyicinin bildiği kadarıyla, ilk argüman o türe göre değerlendirilebilir, bu yüzden kötümser olması gerekir.falsetruefalsedynamic&&

O zaman kodun derlenmesine izin verirse, bu olabilir:

Dinamik bağlayıcı birinciyi değerlendirdiğinde, &&şunları yapar:
- İlk argümanı değerlendirin
- Bu bir T- örtük olarak atıyor bool.
- Oh, bu falseyüzden ikinci argümanı değerlendirmemize gerek yok.
- Değerlendirmenin sonucunu &&ilk bağımsız değişken olarak yapın. (Hayır, falsenedense hayır .)
Dinamik bağlayıcı ikinciyi değerlendirdiğinde, &&şunları yapar:
- İlk argümanı değerlendirin.
- Bu bir T- örtük olarak atıyor bool.
- Oh, trueöyleyse ikinci argümanı değerlendirin.
- ... Kahretsin, batanmamış.

Spesifik terimlerle, kısaca, sadece bir değişkenin "kesinlikle atanmış" veya "kesinlikle atanmamış" olup olmadığını değil, aynı zamanda " falseifadeden sonra kesinlikle atanmış " veya "kesinlikle trueifadeden sonra atanır ".

Bunlar, &&ve ||(ve !ve ??ve ?:) ile uğraşırken , derleyicinin değişkenlerin karmaşık bir boole ifadesinin belirli dallarına atanıp atanamayacağını inceleyebilmesi için vardır.

Ancak, bunlar yalnızca ifadelerin türleri boole kalırken çalışır . İfadenin bir parçası dynamic(veya boole olmayan statik bir tür) olduğunda, artık ifadenin trueveya olduğunu söyleyemeyiz false- bir dahaki sefere boolhangi dalı alacağımıza karar vermek için kullandığımızda, fikrini değiştirmiş olabilir.

Güncelleme: Bu artık çözüldü ve belgelendi :

Dinamik ifadeler için önceki derleyiciler tarafından uygulanan kesin atama kuralları, kesinlikle atanmamış değişkenlerin okunmasına neden olabilecek bazı kod durumlarına izin veriyordu. Bununla ilgili bir rapor için https://github.com/dotnet/roslyn/issues/4509 adresine bakın .

...

Bu olasılık nedeniyle, val'in başlangıç değeri yoksa derleyici bu programın derlenmesine izin vermemelidir. Derleyicinin önceki sürümleri (VS2015'ten önce), val'nin başlangıç değeri olmasa bile bu programın derlenmesine izin veriyordu. Roslyn şimdi, muhtemelen başlatılmamış bir değişkeni okuma girişimini teşhis ediyor.

Question 5

Bu bir hata değil. Bu formun dinamik bir ifadesinin böyle bir atanmamış değişkeni nasıl bırakabileceğine ilişkin bir örnek için https://github.com/dotnet/roslyn/issues/4509#issuecomment-130872713 adresine bakın .