Roslyn không biên dịch được mã

Sau khi tôi đã di chuyển dự án của mình từ VS2013 sang VS2015, dự án không còn được xây dựng nữa. Lỗi biên dịch xảy ra trong câu lệnh LINQ sau:

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

Trình biên dịch trả về một lỗi:

Lỗi CS0165 Sử dụng biến cục bộ chưa được gán 'b'

Nguyên nhân nào gây ra vấn đề này? Có thể sửa nó thông qua cài đặt trình biên dịch không?

Điều gì gây ra vấn đề này?

Đối với tôi, có vẻ như một lỗi trình biên dịch. Ít nhất, nó đã làm. Mặc dù các biểu thức decimal.TryParse(v, out a)và decimal.TryParse(v, out b)biểu thức được đánh giá động, tôi mong đợi trình biên dịch vẫn hiểu rằng vào thời điểm nó đạt đến a <= b, cả hai avà bchắc chắn được gán. Ngay cả với những điều kỳ lạ mà bạn có thể gặp phải khi nhập động, tôi mong rằng sẽ chỉ đánh giá a <= bsau khi đánh giá cả hai TryParsecuộc gọi.

Tuy nhiên, nó chỉ ra rằng thông qua toán tử và chuyển đổi phức tạp, hoàn toàn khả thi để có một biểu thức A && B && Cđánh giá Avà Cnhưng không B- nếu bạn đủ tinh ranh. Xem báo cáo lỗi Roslyn để biết ví dụ tài tình của Neal Gafter.

Thực hiện công việc đó dynamicthậm chí còn khó hơn - ngữ nghĩa liên quan khi toán hạng động khó mô tả hơn, bởi vì để thực hiện giải quyết quá tải, bạn cần đánh giá các toán hạng để tìm ra loại nào có liên quan, điều này có thể phản trực quan. Tuy nhiên, một lần nữa Neal đã đưa ra một ví dụ cho thấy rằng lỗi trình biên dịch là bắt buộc ... đây không phải là một lỗi, đó là một bản sửa lỗi . Neal đã nhận được rất nhiều kudo để chứng minh điều đó.

Có thể sửa nó thông qua cài đặt trình biên dịch không?

Không, nhưng có những lựa chọn thay thế tránh được lỗi.

Thứ nhất, bạn có thể ngăn nó hoạt động - nếu bạn biết rằng bạn sẽ chỉ sử dụng chuỗi, thì bạn có thể sử dụng IEnumerable<string> hoặc cung cấp cho biến phạm vi vmột loại string(tức là from string v in array). Đó sẽ là lựa chọn ưu tiên của tôi.

Nếu bạn thực sự cần giữ cho nó động, chỉ cần cung cấp bmột giá trị để bắt đầu bằng:

decimal a, b = 0m;

Điều này sẽ không gây hại gì - chúng tôi biết rằng thực sự đánh giá động của bạn sẽ không gây ra bất kỳ điều gì điên rồ, vì vậy cuối cùng bạn sẽ vẫn chỉ định một giá trị btrước khi sử dụng nó, khiến giá trị ban đầu không liên quan.

Ngoài ra, có vẻ như việc thêm dấu ngoặc đơn cũng hoạt động:

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

Điều đó thay đổi thời điểm kích hoạt các phần giải quyết quá tải khác nhau và tình cờ làm cho trình biên dịch hài lòng.

Vẫn còn một vấn đề - các quy tắc của đặc tả về việc gán xác định với &&toán tử cần được làm rõ để nêu rõ rằng chúng chỉ áp dụng khi &&toán tử đang được sử dụng trong triển khai "thông thường" với hai booltoán hạng. Tôi sẽ cố gắng đảm bảo điều này được khắc phục cho tiêu chuẩn ECMA tiếp theo.

Đây dường như là một lỗi, hoặc ít nhất là một hồi quy, trong trình biên dịch Roslyn. Lỗi sau đã được gửi để theo dõi nó:

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

Trong khi đó, câu trả lời xuất sắc của Jon có một vài cách giải quyết.

Vì tôi đã học rất chăm chỉ trong báo cáo lỗi, tôi sẽ cố gắng giải thích điều này bản thân mình.

Hãy tưởng tượng Tlà một số kiểu do người dùng xác định với một kiểu truyền ngầm boolthay thế giữa falsevà true, bắt đầu bằng false. Theo như trình biên dịch biết, dynamicđối số đầu tiên đối với đối số đầu tiên &&có thể đánh giá theo kiểu đó, vì vậy nó phải bi quan.

Sau đó, nếu nó cho phép mã biên dịch, điều này có thể xảy ra:

• Khi chất kết dính động đánh giá kết quả đầu tiên &&, nó thực hiện như sau:
  • Đánh giá đối số đầu tiên
  • Đó là một T- ẩn nó đến bool.
  • Ồ, đó là false, vì vậy chúng ta không cần đánh giá đối số thứ hai.
  • Đặt kết quả của &&đánh giá là đối số đầu tiên. (Không, không phải false, vì một số lý do.)
• Khi chất kết dính động đánh giá thứ hai &&, nó thực hiện như sau:
  • Đánh giá lập luận đầu tiên.
  • Đó là một T- ẩn nó đến bool.
  • Ồ, vậy true, hãy đánh giá lập luận thứ hai.
  • ... Ồ, bkhông được chỉ định.

Tóm lại, trong thuật ngữ cụ thể, có các quy tắc "gán xác định" đặc biệt cho phép chúng ta không chỉ nói liệu một biến được "chắc chắn chỉ định" hay "không chắc chắn được gán", mà còn nếu nó "chắc chắn được gán sau falsecâu lệnh" hoặc "chắc chắn được gán sau truecâu lệnh ”.

Chúng tồn tại để khi xử lý &&và ||(và !và ??và ?:) trình biên dịch có thể kiểm tra xem các biến có thể được gán trong các nhánh cụ thể của một biểu thức boolean phức tạp hay không.

Tuy nhiên, những điều này chỉ hoạt động trong khi kiểu của biểu thức vẫn là boolean . Khi một phần của biểu thức là dynamic(hoặc kiểu tĩnh không boolean), chúng ta không còn có thể nói một cách đáng tin cậy rằng biểu thức đó là truehoặc false- lần tiếp theo chúng ta ép kiểu boolđể quyết định nhánh nào sẽ sử dụng, nó có thể đã thay đổi ý định.

Cập nhật: điều này hiện đã được giải quyết và ghi lại :

Các quy tắc gán xác định được thực hiện bởi các trình biên dịch trước đó cho các biểu thức động cho phép một số trường hợp mã có thể dẫn đến việc đọc các biến mà không chắc chắn được gán. Xem https://github.com/dotnet/roslyn/issues/4509 để biết một báo cáo về điều này.

...

Vì khả năng này, trình biên dịch không được phép biên dịch chương trình này nếu val không có giá trị ban đầu. Các phiên bản trước của trình biên dịch (trước VS2015) cho phép chương trình này biên dịch ngay cả khi val không có giá trị ban đầu. Roslyn hiện chẩn đoán nỗ lực này để đọc một biến có thể chưa được khởi tạo.

Đây không phải là một lỗi. Xem https://github.com/dotnet/roslyn/issues/4509#issuecomment-130872713 để biết ví dụ về cách một biểu thức động của biểu mẫu này có thể để lại một biến không được gán như vậy.