Roslyn รวบรวมโค้ดไม่สำเร็จ

Question 1

หลังจากที่ฉันย้ายโปรเจ็กต์ของฉันจาก VS2013 เป็น VS2015 โปรเจ็กต์จะไม่สร้างอีกต่อไป ข้อผิดพลาดในการคอมไพล์เกิดขึ้นในคำสั่ง 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();
}

คอมไพเลอร์ส่งคืนข้อผิดพลาด:

ข้อผิดพลาด CS0165 การใช้ตัวแปรภายในที่ไม่ได้กำหนด 'b'

สาเหตุของปัญหานี้คืออะไร? เป็นไปได้ไหมที่จะแก้ไขผ่านการตั้งค่าคอมไพเลอร์

Question 2

อะไรทำให้เกิดปัญหานี้

ดูเหมือนว่าคอมไพเลอร์บั๊กสำหรับฉัน อย่างน้อยก็ทำได้ แม้ว่านิพจน์decimal.TryParse(v, out a)และdecimal.TryParse(v, out b)จะได้รับการประเมินแบบไดนามิก แต่ฉันคาดว่าคอมไพเลอร์จะยังคงเข้าใจว่าเมื่อถึงเวลาที่กำหนดa <= bทั้งสองอย่างaและbได้รับมอบหมายอย่างแน่นอน แม้จะมีความแปลกประหลาดที่คุณสามารถทำได้ในการพิมพ์แบบไดนามิกฉันคาดหวังว่าจะประเมินa <= bหลังจากประเมินการTryParseโทรทั้งสองครั้งแล้วเท่านั้น

อย่างไรก็ตามปรากฎว่าด้วยตัวดำเนินการและการแปลงที่ยุ่งยากมันเป็นไปได้ทั้งหมดที่จะมีนิพจน์A && B && Cที่ประเมินค่าAและCแต่ไม่ใช่B- หากคุณมีไหวพริบเพียงพอ ดูรายงานข้อบกพร่องของ Roslynสำหรับตัวอย่างอันชาญฉลาดของ Neal Gafter

การทำให้งานdynamicนั้นยากขึ้นไปอีก - ความหมายที่เกี่ยวข้องเมื่อตัวถูกดำเนินการเป็นแบบไดนามิกนั้นอธิบายได้ยากกว่าเนื่องจากในการดำเนินการแก้ปัญหาโอเวอร์โหลดคุณจำเป็นต้องประเมินตัวถูกดำเนินการเพื่อดูว่าประเภทใดที่เกี่ยวข้องซึ่งสามารถตอบโต้ได้ง่าย อย่างไรก็ตามอีกครั้งโอนีลได้เกิดขึ้นกับตัวอย่างที่แสดงให้เห็นว่าข้อผิดพลาดคอมไพเลอร์จะต้องเ ... นี้ไม่ได้เป็นข้อผิดพลาดก็เป็นข้อผิดพลาดการแก้ไข ความรุ่งโรจน์จำนวนมากต่อโอนีลเพื่อพิสูจน์มัน

เป็นไปได้ไหมที่จะแก้ไขผ่านการตั้งค่าคอมไพเลอร์

ไม่ แต่มีทางเลือกอื่นที่หลีกเลี่ยงข้อผิดพลาด

ประการแรกคุณสามารถหยุดไม่ให้เป็นแบบไดนามิก - หากคุณรู้ว่าคุณจะใช้สตริงเพียงอย่างเดียวคุณสามารถใช้IEnumerable<string> หรือกำหนดตัวแปรช่วงvเป็นประเภทstring(เช่นfrom string v in array) ได้ นั่นจะเป็นตัวเลือกที่ฉันต้องการ

หากคุณต้องการให้ไดนามิกจริงๆเพียงแค่ให้bค่าเริ่มต้นด้วย:

decimal a, b = 0m;

สิ่งนี้จะไม่ทำอันตรายใด ๆ - เรารู้ดีว่าจริงๆแล้วการประเมินแบบไดนามิกของคุณจะไม่ทำอะไรที่บ้าคลั่งดังนั้นคุณจะยังคงกำหนดค่าให้bก่อนที่คุณจะใช้มันทำให้ค่าเริ่มต้นไม่เกี่ยวข้อง

นอกจากนี้ดูเหมือนว่าการเพิ่มวงเล็บก็ใช้ได้เช่นกัน:

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

นั่นจะเปลี่ยนจุดที่ทริกเกอร์ความละเอียดโอเวอร์โหลดชิ้นต่างๆและเกิดขึ้นเพื่อทำให้คอมไพเลอร์พอใจ

นอกจากนี้หนึ่งในปัญหาที่ยังเหลือ - กฎข้อมูลจำเพาะของที่ได้รับมอบหมายที่ชัดเจนกับ&&ความต้องการผู้ประกอบการที่จะชี้แจงให้กับรัฐที่พวกเขาใช้เฉพาะเมื่อ&&ผู้ประกอบการจะถูกนำมาใช้ในการดำเนินงานของ "ปกติ" มีสองboolตัวถูกดำเนินการ ฉันจะพยายามทำให้แน่ใจว่าสิ่งนี้ได้รับการแก้ไขสำหรับมาตรฐาน ECMA ถัดไป

Question 3

สิ่งนี้ดูเหมือนจะเป็นจุดบกพร่องหรืออย่างน้อยที่สุดก็คือการถดถอยในคอมไพเลอร์ Roslyn มีการยื่นข้อบกพร่องต่อไปนี้เพื่อติดตาม:

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

ในขณะเดียวกันคำตอบที่ยอดเยี่ยมของจอนมีอยู่สองประการ

Question 4

เนื่องจากฉันได้รับการศึกษาอย่างหนักในรายงานข้อบกพร่องฉันจะพยายามอธิบายเรื่องนี้ด้วยตัวเอง

ลองนึกภาพTบางประเภทที่ผู้ใช้กำหนดด้วยการหล่อโดยปริยายที่จะboolสลับกันไปมาระหว่างที่falseและเริ่มต้นด้วยtrue falseเท่าที่คอมไพลเลอร์รู้dynamicอาร์กิวเมนต์แรกถึงตัวแรก&&อาจประเมินเป็นประเภทนั้นดังนั้นจึงต้องมองโลกในแง่ร้าย

จากนั้นหากปล่อยให้โค้ดคอมไพล์สิ่งนี้อาจเกิดขึ้น:

เมื่อตัวประสานแบบไดนามิกประเมินค่าแรก&&จะทำสิ่งต่อไปนี้:
- ประเมินอาร์กิวเมนต์แรก
- มันเป็นT- boolโดยปริยายโยนมันทิ้งไป
- โอ้มันเป็นfalseเช่นนั้นเราไม่จำเป็นต้องประเมินข้อโต้แย้งที่สอง
- ทำให้ผลลัพธ์ของการ&&ประเมินเป็นอาร์กิวเมนต์แรก (ไม่ไม่falseด้วยเหตุผลบางประการ)
เมื่อตัวประสานแบบไดนามิกประเมินวินาที&&จะทำสิ่งต่อไปนี้:
- ประเมินอาร์กิวเมนต์แรก
- มันเป็นT- boolโดยปริยายโยนมันทิ้งไป
- โอ้มันเป็นtrueเช่นนั้นเพื่อประเมินข้อโต้แย้งที่สอง
- ... โอ้อึbไม่ได้รับมอบหมาย

กล่าวโดยสรุปสั้น ๆ ว่ามีกฎ "การมอบหมายที่แน่นอน" พิเศษซึ่งช่วยให้เราสามารถบอกได้ว่าตัวแปรนั้น "กำหนดแน่นอน" หรือ "ไม่ได้กำหนดแน่นอน" แต่ยังรวมถึง "กำหนดหลังfalseคำสั่ง" หรือ "แน่นอน มอบหมายหลังtrueคำสั่ง ".

ที่มีอยู่เหล่านี้เพื่อที่ว่าเมื่อจัดการกับ&&และ||(และ!และ??และ?:) คอมไพเลอร์สามารถตรวจสอบว่าตัวแปรที่อาจได้รับมอบหมายในสาขาเฉพาะของนิพจน์บูลีนที่ซับซ้อน

แต่เหล่านี้ทำงานเท่านั้นในขณะที่ประเภทการแสดงออกยังคงบูล เมื่อส่วนหนึ่งของนิพจน์เป็นdynamic(หรือประเภทคงที่ที่ไม่ใช่บูลีน) เราไม่สามารถพูดได้อย่างน่าเชื่อถืออีกต่อไปว่านิพจน์นั้นเป็นtrueหรือfalse- ในครั้งต่อไปที่เราโยนมันboolเพื่อตัดสินใจว่าจะใช้สาขาใดมันอาจเปลี่ยนใจ

อัปเดต: ขณะนี้ได้รับการแก้ไขและจัดทำเป็นเอกสาร :

กฎการกำหนดที่แน่นอนที่ใช้โดยคอมไพเลอร์ก่อนหน้าสำหรับนิพจน์แบบไดนามิกอนุญาตให้มีโค้ดบางกรณีที่อาจส่งผลให้มีการอ่านตัวแปรที่ไม่ได้กำหนดไว้อย่างแน่นอน ดูhttps://github.com/dotnet/roslyn/issues/4509สำหรับรายงานเรื่องนี้

...

เนื่องจากความเป็นไปได้นี้คอมไพเลอร์จะต้องไม่อนุญาตให้คอมไพล์โปรแกรมนี้หาก val ไม่มีค่าเริ่มต้น คอมไพเลอร์เวอร์ชันก่อนหน้า (ก่อน VS2015) อนุญาตให้โปรแกรมนี้คอมไพล์แม้ว่า val จะไม่มีค่าเริ่มต้นก็ตาม ขณะนี้ Roslyn วินิจฉัยความพยายามนี้เพื่ออ่านตัวแปรที่อาจไม่ได้กำหนดค่าเริ่มต้น

Question 5

นี่ไม่ใช่บั๊ก ดูhttps://github.com/dotnet/roslyn/issues/4509#issuecomment-130872713สำหรับตัวอย่างว่านิพจน์ไดนามิกของแบบฟอร์มนี้สามารถปล่อยให้ตัวแปร out นั้นไม่ได้กำหนดได้อย่างไร