Roslyn gagal mengkompilasi kode

Setelah saya memindahkan proyek saya dari VS2013 ke VS2015, proyek tersebut tidak lagi dibangun. Terjadi galat kompilasi dalam pernyataan LINQ berikut ini:

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 mengembalikan kesalahan:

Kesalahan CS0165 Penggunaan variabel lokal 'b' yang tidak ditetapkan

Apa penyebab masalah ini? Apakah mungkin untuk memperbaikinya melalui pengaturan kompilator?

Apa penyebab masalah ini?

Sepertinya bug kompiler bagi saya. Setidaknya, memang begitu. Meskipun ekspresi decimal.TryParse(v, out a)dan decimal.TryParse(v, out b)dievaluasi secara dinamis, saya berharap kompilator masih memahami bahwa pada saat mencapai a <= b, keduanya adan bsudah pasti ditetapkan. Bahkan dengan keanehan yang dapat Anda temukan dalam pengetikan dinamis, saya berharap untuk hanya mengevaluasi a <= bsetelah mengevaluasi kedua TryParsepanggilan tersebut.

Namun, ternyata melalui operator dan konversi yang rumit, sangat mungkin untuk memiliki ekspresi A && B && Cyang mengevaluasi Adan Ctetapi tidak B- jika Anda cukup licik. Lihat laporan bug Roslyn untuk contoh cerdik Neal Gafter.

Membuatnya bekerja dengan dynamiclebih sulit - semantik yang terlibat saat operan dinamis lebih sulit untuk dijelaskan, karena untuk melakukan resolusi kelebihan beban, Anda perlu mengevaluasi operan untuk mengetahui jenis apa yang terlibat, yang dapat menjadi kontra-intuitif. Namun, sekali lagi Neal memberikan contoh yang menunjukkan bahwa kesalahan kompilator diperlukan ... ini bukan bug, ini perbaikan bug . Pujian dalam jumlah besar untuk Neal karena telah membuktikannya.

Apakah mungkin untuk memperbaikinya melalui pengaturan kompiler?

Tidak, tetapi ada alternatif yang menghindari kesalahan tersebut.

Pertama, Anda dapat menghentikannya agar tidak dinamis - jika Anda tahu bahwa Anda hanya akan pernah menggunakan string, maka Anda dapat menggunakan IEnumerable<string> atau memberikan variabel rentang vjenis string(yaitu from string v in array). Itu akan menjadi pilihan yang saya sukai.

Jika Anda benar - benar perlu menjaganya tetap dinamis, berikan bnilai sebagai permulaan:

decimal a, b = 0m;

Ini tidak akan merugikan - kami tahu bahwa sebenarnya evaluasi dinamis Anda tidak akan melakukan sesuatu yang gila, jadi Anda tetap akan menetapkan nilai bsebelum Anda menggunakannya, membuat nilai awal tidak relevan.

Selain itu, tampaknya menambahkan tanda kurung juga berfungsi:

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

Itu mengubah titik di mana berbagai bagian resolusi berlebih dipicu, dan kebetulan membuat kompiler senang.

Ada satu masalah yang masih tersisa - aturan spesifikasi tentang penetapan pasti dengan &&operator perlu diklarifikasi untuk menyatakan bahwa mereka hanya berlaku ketika &&operator sedang digunakan dalam implementasi "reguler" dengan dua booloperan. Saya akan mencoba untuk memastikan ini diperbaiki untuk standar ECMA berikutnya.

Ini tampaknya bug, atau setidaknya regresi, dalam kompiler Roslyn. Bug berikut telah diajukan untuk melacaknya:

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

Sementara itu, jawaban bagus Jon memiliki beberapa solusi.

Karena saya disekolahkan begitu keras dalam laporan bug, saya akan mencoba menjelaskannya sendiri.

Bayangkan Tadalah beberapa tipe yang ditentukan pengguna dengan pemeran implisit boolyang bergantian antara falsedan true, dimulai dengan false. Sejauh yang diketahui kompilator, dynamicargumen pertama ke argumen pertama &&mungkin mengevaluasi tipe itu, jadi itu harus pesimis.

Jika, kemudian, membiarkan kode dikompilasi, ini bisa terjadi:

• Saat pengikat dinamis mengevaluasi yang pertama &&, ia melakukan hal berikut:
  • Evaluasi argumen pertama
  • Ini T- secara implisit melemparkannya ke bool.
  • Oh, ya false, jadi kita tidak perlu mengevaluasi argumen kedua.
  • Jadikan hasil &&evaluasi sebagai argumen pertama. (Tidak, tidak false, untuk beberapa alasan.)
• Saat pengikat dinamis mengevaluasi yang kedua &&, ia melakukan hal berikut:
  • Evaluasi argumen pertama.
  • Ini T- secara implisit melemparkannya ke bool.
  • Oh, ya true, jadi evaluasi argumen kedua.
  • ... Oh sial, btidak ditugaskan.

Dalam istilah spesifikasi, singkatnya, ada aturan khusus "penugasan pasti" yang memungkinkan kita mengatakan tidak hanya apakah suatu variabel "ditetapkan secara pasti" atau "tidak ditetapkan secara pasti", tetapi juga jika ia "ditetapkan secara pasti setelah falsepernyataan" atau "pasti ditugaskan setelah truepernyataan ".

Ini ada sehingga ketika berhadapan dengan &&dan ||(dan !dan ??dan ?:) kompilator dapat memeriksa apakah variabel dapat ditugaskan di cabang tertentu dari ekspresi boolean kompleks.

Namun, ini hanya berfungsi jika tipe ekspresi tetap boolean . Jika bagian dari ekspresi adalah dynamic(atau tipe statis non-boolean), kami tidak dapat lagi mengatakan dengan andal bahwa ekspresi tersebut adalah trueatau false- saat berikutnya kami mentransmisikannya booluntuk memutuskan cabang mana yang akan diambil, mungkin telah berubah pikiran.

Pembaruan: ini sekarang telah diselesaikan dan didokumentasikan :

Aturan penetapan pasti yang diterapkan oleh kompiler sebelumnya untuk ekspresi dinamis memungkinkan beberapa kasus kode yang dapat mengakibatkan variabel yang dibaca tidak ditetapkan secara pasti. Lihat https://github.com/dotnet/roslyn/issues/4509 untuk satu laporan tentang ini.

...

Karena kemungkinan ini, kompilator tidak boleh mengizinkan program ini untuk dikompilasi jika val tidak memiliki nilai awal. Versi kompilator sebelumnya (sebelum VS2015) memungkinkan program ini untuk dikompilasi meskipun val tidak memiliki nilai awal. Roslyn sekarang mendiagnosis upaya untuk membaca variabel yang mungkin tidak diinisialisasi ini.

Ini bukan bug. Lihat https://github.com/dotnet/roslyn/issues/4509#issuecomment-130872713 untuk contoh bagaimana ekspresi dinamis dari formulir ini dapat membiarkan variabel seperti itu tidak ditetapkan.