ดูเหมือนว่า GCC และ LLVM-Clang กำลังใช้ตัวแยกวิเคราะห์การสืบเชื้อสายแบบเรียกซ้ำที่เขียนด้วยลายมือและไม่ได้สร้างด้วยเครื่องโดยใช้ Bison-Flex การแยกวิเคราะห์จากล่างขึ้นบน
ขอคนที่นี่ช่วยยืนยันว่าเป็นกรณีนี้ได้ไหม และถ้าเป็นเช่นนั้นเหตุใดเฟรมเวิร์กคอมไพเลอร์หลักจึงใช้ตัวแยกวิเคราะห์ที่เขียนด้วยลายมือ
อัปเดต : บล็อกที่น่าสนใจในหัวข้อนี้ที่นี่
คำตอบ:
ใช่:
GCC ใช้ตัวแยกวิเคราะห์ yacc (วัวกระทิง) นาน ๆ ครั้ง แต่มันถูกแทนที่ด้วยตัวแยกวิเคราะห์โคตรซ้ำที่เขียนด้วยมือในบางช่วงของซีรีส์ 3.x: ดูhttp://gcc.gnu.org/wiki/New_C_Parserสำหรับ ลิงก์ไปยังการส่งโปรแกรมแก้ไขที่เกี่ยวข้อง
เสียงดังกราวยังใช้ parser โคตร recursive ที่เขียนด้วยมือ: ดูส่วน "A parser ปึกแผ่นเดียวสำหรับ C, วัตถุประสงค์ C, C ++ และวัตถุประสงค์ C ++" ใกล้ถึงจุดสิ้นสุดของhttp://clang.llvm.org/features.html
foo * bar;สามารถแยกวิเคราะห์เป็นทั้งการแสดงออกคูณ (กับผลที่ไม่ได้ใช้) หรือประกาศของตัวแปรที่มีประเภทตัวชี้-to-bar fooข้อใดถูกต้องขึ้นอยู่กับว่า a typedeffor fooอยู่ในขอบเขตในขณะนั้นซึ่งไม่ใช่สิ่งที่สามารถกำหนดได้ด้วยจำนวนผู้มอง แต่นั่นหมายความว่าตัวแยกวิเคราะห์การสืบเชื้อสายแบบเรียกซ้ำจำเป็นต้องมีการเพิ่มเครื่องจักรพิเศษที่น่าเกลียดเพื่อจัดการกับสิ่งนั้น
มีทฤษฎีบทชาวบ้านที่บอกว่า C นั้นยากที่จะแยกวิเคราะห์และโดยพื้นฐานแล้ว C ++ เป็นไปไม่ได้
มันไม่เป็นความจริง
สิ่งที่เป็นความจริงก็คือ C และ C ++ นั้นค่อนข้างยากที่จะแยกวิเคราะห์โดยใช้ตัวแยกวิเคราะห์ LALR (1) โดยไม่ต้องแฮ็คเครื่องจักรในการแยกวิเคราะห์และทำให้ข้อมูลตารางสัญลักษณ์ยุ่งเหยิง ในความเป็นจริงแล้ว GCC ใช้ในการแยกวิเคราะห์โดยใช้ YACC และแฮ็กเกอร์เพิ่มเติมเช่นนี้และใช่มันน่าเกลียด ตอนนี้ GCC ใช้ตัวแยกวิเคราะห์ที่เขียนด้วยลายมือ แต่ยังคงใช้แฮ็กเกอร์ตารางสัญลักษณ์ ชาวเสียงดังไม่เคยพยายามใช้เครื่องแยกวิเคราะห์อัตโนมัติ AFAIK ตัวแยกวิเคราะห์เสียงดังได้รับการเข้ารหัสแบบเรียกซ้ำเสมอ
ความจริงก็คือ C และ C ++ นั้นค่อนข้างง่ายในการแยกวิเคราะห์ด้วยตัวแยกวิเคราะห์ที่สร้างขึ้นโดยอัตโนมัติที่แข็งแกร่งกว่าเช่นตัวแยกวิเคราะห์ GLRและคุณไม่จำเป็นต้องแฮ็กใด ๆ Elsa c ++ แยกวิเคราะห์เป็นตัวอย่างหนึ่งของเรื่องนี้ Front End C ++ของเราเป็นอีกส่วนหนึ่ง (เช่นเดียวกับส่วนหน้า "คอมไพเลอร์" ของเรา GLR เป็นเทคโนโลยีการแยกวิเคราะห์ที่ยอดเยี่ยมมาก)
ส่วนหน้า C ++ ของเราไม่เร็วเท่า GCC และช้ากว่า Elsa อย่างแน่นอน เราใช้พลังงานเพียงเล็กน้อยในการปรับแต่งมันอย่างระมัดระวังเพราะเรามีปัญหาเร่งด่วนอื่น ๆ อีก (อย่างไรก็ตามมันถูกใช้กับโค้ด C ++ หลายล้านบรรทัด) Elsa น่าจะช้ากว่า GCC เพียงเพราะมันเป็นเรื่องทั่วไป ด้วยความเร็วโปรเซสเซอร์ในปัจจุบันความแตกต่างเหล่านี้อาจไม่สำคัญมากนักในทางปฏิบัติ
แต่ "คอมไพเลอร์ตัวจริง" ที่เผยแพร่กันอย่างแพร่หลายในปัจจุบันมีรากฐานมาจากคอมไพเลอร์เมื่อ 10 หรือ 20 ปีก่อนหรือมากกว่านั้น จากนั้นความไร้ประสิทธิภาพก็มีความสำคัญมากขึ้นและไม่มีใครเคยได้ยินเกี่ยวกับตัวแยกวิเคราะห์ GLR ดังนั้นผู้คนจึงทำในสิ่งที่พวกเขารู้ว่าต้องทำอย่างไร เสียงดังขึ้นเป็นเรื่องล่าสุด แต่แล้วทฤษฎีบทชาวบ้านก็ยังคงรักษา "การโน้มน้าวใจ" ไว้เป็นเวลานาน
คุณไม่จำเป็นต้องทำแบบนั้นอีกต่อไป คุณสามารถใช้ GLR และตัวแยกวิเคราะห์อื่น ๆ เป็นส่วนหน้าได้อย่างสมเหตุสมผลโดยมีการปรับปรุงการบำรุงรักษาคอมไพเลอร์
สิ่งที่เป็นความจริงก็คือการได้รับไวยากรณ์ที่ตรงกับพฤติกรรมของคอมไพเลอร์เพื่อนบ้านที่เป็นมิตรของคุณนั้นยาก ในขณะที่คอมไพเลอร์ C ++ เกือบทั้งหมดใช้มาตรฐานดั้งเดิม (ส่วนใหญ่) แต่ก็มักจะมีส่วนขยายมุมมืดมากมายเช่นข้อกำหนด DLL ในคอมไพเลอร์ MS เป็นต้นหากคุณมีเครื่องมือแยกวิเคราะห์ที่แข็งแกร่งคุณสามารถใช้เวลาของคุณในการพยายามหา ไวยากรณ์ขั้นสุดท้ายเพื่อให้ตรงกับความเป็นจริงแทนที่จะพยายามดัดไวยากรณ์ของคุณเพื่อให้ตรงกับข้อ จำกัด ของตัวสร้างโปรแกรมแยกวิเคราะห์ของคุณ
แก้ไขพฤศจิกายน 2555: ตั้งแต่เขียนคำตอบนี้เราได้ปรับปรุงส่วนหน้า C ++ ของเราเพื่อรองรับ C ++ 11 แบบเต็มรวมถึงภาษาถิ่น ANSI, GNU และ MS ในขณะที่มีสิ่งพิเศษมากมายเราไม่จำเป็นต้องเปลี่ยนเครื่องมือแยกวิเคราะห์ของเรา เราเพิ่งแก้ไขกฎไวยากรณ์ เราไม่ต้องเปลี่ยนการวิเคราะห์ความหมาย; C ++ 11 มีความซับซ้อนมากในเชิงความหมายและงานนี้ทำให้ความพยายามในการเรียกใช้โปรแกรมแยกวิเคราะห์
แก้ไขกุมภาพันธ์ 2015: ... ตอนนี้จัดการ C ++ 14 แบบเต็ม (ดูรับ AST ที่มนุษย์สามารถอ่านได้จากรหัส c ++สำหรับการแยกวิเคราะห์ GLR ของรหัสบิตธรรมดาและ "การแยกวิเคราะห์ที่น่าอับอายที่สุดของ C ++")
แก้ไขเมษายน 2017: ตอนนี้จัดการ (ร่าง) C ++ 17
foo * bar;ความคลุมเครือนั้นได้อย่างไร?
ตัวแยกวิเคราะห์ของ Clang เป็นตัวแยกวิเคราะห์แบบเรียกซ้ำที่เขียนด้วยมือเช่นเดียวกับส่วนหน้า C และ C ++ แบบโอเพนซอร์สและเชิงพาณิชย์อื่น ๆ
Clang ใช้ตัวแยกวิเคราะห์การสืบเชื้อสายซ้ำด้วยเหตุผลหลายประการ:
โดยรวมแล้วสำหรับคอมไพเลอร์ C ++ มันก็ไม่สำคัญมากนัก: ส่วนการแยกวิเคราะห์ของ C ++ นั้นไม่สำคัญ แต่ก็ยังเป็นส่วนที่ง่ายกว่าดังนั้นจึงต้องจ่ายเพื่อให้ง่าย การวิเคราะห์เชิงความหมาย - โดยเฉพาะการค้นหาชื่อการเริ่มต้นความละเอียดเกินและการสร้างอินสแตนซ์เทมเพลต --- เป็นคำสั่งขนาดที่ซับซ้อนกว่าการแยกวิเคราะห์ หากคุณต้องการการพิสูจน์ให้ตรวจสอบการกระจายของโค้ดและคอมโพเนนต์ "Sema" ของ Clang (สำหรับการวิเคราะห์เชิงความหมาย) เทียบกับองค์ประกอบ "Parse" (สำหรับการแยกวิเคราะห์)
ตัวแยกวิเคราะห์ของ gcc เขียนด้วยลายมือ . ฉันสงสัยเหมือนกันสำหรับเสียงดัง อาจเป็นเพราะสาเหตุบางประการ:
นี่อาจไม่ใช่กรณีของกลุ่มอาการ "ไม่ได้คิดค้นที่นี่" แต่เป็นมากกว่านั้นตามแนวของ "ไม่มีอะไรที่ปรับให้เหมาะกับสิ่งที่เราต้องการโดยเฉพาะดังนั้นเราจึงเขียนของเราเอง"
มีคำตอบแปลก ๆ !
ไวยากรณ์ C / C ++ ไม่ใช่บริบทฟรี พวกเขามีความอ่อนไหวต่อบริบทเนื่องจากแถบ Foo * ความคลุมเครือ เราต้องสร้างรายการของ typedef เพื่อให้ทราบว่า Foo เป็นประเภทหรือไม่
Ira Baxter: ฉันไม่เห็นประเด็นกับสิ่ง GLR ของคุณ ทำไมต้องสร้างต้นไม้แยกวิเคราะห์ซึ่งประกอบด้วยความคลุมเครือ การแยกวิเคราะห์หมายถึงการแก้ความคลุมเครือการสร้างโครงสร้างไวยากรณ์ คุณแก้ไขความคลุมเครือเหล่านี้ในรอบที่สองดังนั้นสิ่งนี้จึงไม่น่าเกลียดน้อยลง สำหรับฉันมันน่าเกลียดกว่ามาก ...
Yacc เป็นตัวสร้างตัวแยกวิเคราะห์ LR (1) (หรือ LALR (1)) แต่สามารถแก้ไขได้อย่างง่ายดายเพื่อให้มีความอ่อนไหวตามบริบท และไม่มีอะไรน่าเกลียดอยู่ในนั้น Yacc / Bison ถูกสร้างขึ้นเพื่อช่วยในการแยกวิเคราะห์ภาษา C ดังนั้นอาจไม่ใช่เครื่องมือที่น่าเกลียดที่สุดในการสร้างตัวแยกวิเคราะห์ C ...
จนกว่า GCC 3.x ตัวแยกวิเคราะห์ C จะถูกสร้างขึ้นโดย yacc / bison โดยมีตาราง typedefs ที่สร้างขึ้นระหว่างการแยกวิเคราะห์ ด้วยการสร้างตาราง typedefs "ในการแยกวิเคราะห์" ไวยากรณ์ C จะกลายเป็นบริบทที่ไม่มีในท้องถิ่นและยิ่งไปกว่านั้น "เฉพาะ LR (1)"
ตอนนี้ใน Gcc 4.x เป็นตัวแยกวิเคราะห์การสืบเชื้อสายแบบเรียกซ้ำ มันเป็นตัวแยกวิเคราะห์เดียวกันกับใน Gcc 3.x โดยยังคงเป็น LR (1) และมีกฎไวยากรณ์เหมือนกัน ความแตกต่างคือตัวแยกวิเคราะห์ yacc ถูกเขียนด้วยมือตอนนี้ shift / ลดจะซ่อนอยู่ใน call stack และไม่มี "state454: if (nextsym == '(') goto state398" เหมือนใน gcc 3.x yacc's โปรแกรมแยกวิเคราะห์จึงง่ายต่อการแก้ไขจัดการข้อผิดพลาดและพิมพ์ข้อความที่ดีกว่าและดำเนินการขั้นตอนการคอมไพล์ถัดไประหว่างการแยกวิเคราะห์ในราคาที่ "อ่านง่าย" น้อยกว่ามากสำหรับรหัส gcc
เหตุใดพวกเขาจึงเปลี่ยนจาก yacc เป็นการสืบเชื้อสายซ้ำ เนื่องจากมีความจำเป็นมากที่จะต้องหลีกเลี่ยง yacc ในการแยกวิเคราะห์ C ++ และเนื่องจาก GCC ใฝ่ฝันที่จะเป็นคอมไพเลอร์หลายภาษานั่นคือการแชร์โค้ดสูงสุดระหว่างภาษาต่างๆที่สามารถคอมไพล์ได้ นี่คือสาเหตุที่ตัวแยกวิเคราะห์ C ++ และ C เขียนในลักษณะเดียวกัน
C ++ แยกวิเคราะห์ได้ยากกว่า C เนื่องจากไม่ใช่ LR (1) แบบ "เฉพาะที่" เป็น C ไม่ใช่แม้แต่ LR (k) ดูที่func<4 > 2>ซึ่งเป็นฟังก์ชั่นแม่แบบ instantiated 4> 2 คือจะต้องมีการอ่านเป็นfunc<4 > 2>
func<1>นี่ไม่ใช่ LR (1) อย่างแน่นอน ตอนนี้พิจารณาfunc<4 > 2 > 1 > 3 > 3 > 8 > 9 > 8 > 7 > 8>. นี่คือที่ที่การสืบเชื้อสายซ้ำสามารถแก้ความคลุมเครือได้อย่างง่ายดายในราคาของการเรียกใช้ฟังก์ชันเพิ่มเติมอีกสองสามครั้ง (parse_template_parameter คือฟังก์ชันตัวแยกวิเคราะห์ที่ไม่ชัดเจนหาก parse_template_parameter (17tokens) ล้มเหลวให้ลองอีกครั้ง parse_template_parameter (15tokens), parse_template_paramens) ... จนถึง 13tokens มันได้ผล).
ฉันไม่รู้ว่าทำไมจึงไม่สามารถเพิ่มไวยากรณ์ย่อยซ้ำ yacc / bison ได้บางทีนี่อาจเป็นขั้นตอนต่อไปในการพัฒนาตัวแยกวิเคราะห์ gcc / GNU
ดูเหมือนว่า GCC และ LLVM-Clang กำลังใช้ตัวแยกวิเคราะห์การสืบเชื้อสายแบบเรียกซ้ำที่เขียนด้วยลายมือและไม่ได้สร้างด้วยเครื่องโดยใช้ Bison-Flex การแยกวิเคราะห์จากล่างขึ้นบน
โดยเฉพาะอย่างยิ่ง Bison ฉันไม่คิดว่าจะสามารถจัดการกับไวยากรณ์ได้โดยไม่ต้องแยกวิเคราะห์บางสิ่งอย่างคลุมเครือและทำครั้งที่สองในภายหลัง
ฉันรู้ว่า Happy ของ Haskell อนุญาตให้มีตัวแยกวิเคราะห์ monadic (เช่นขึ้นอยู่กับรัฐ) ที่สามารถแก้ไขปัญหาเฉพาะกับไวยากรณ์ C ได้ แต่ฉันรู้ว่าไม่มีตัวสร้างตัวแยกวิเคราะห์ C ที่อนุญาตให้ monad ของรัฐที่ผู้ใช้จัดหาให้
ตามทฤษฎีแล้วการกู้คืนข้อผิดพลาดจะเป็นจุดที่ช่วยให้โปรแกรมแยกวิเคราะห์ที่เขียนด้วยลายมือ แต่ประสบการณ์ของฉันกับ GCC / Clang พบว่าข้อความแสดงข้อผิดพลาดไม่ดีเป็นพิเศษ
สำหรับประสิทธิภาพ - การอ้างสิทธิ์บางส่วนดูเหมือนจะไม่มีเหตุผล การสร้างเครื่องขนาดใหญ่โดยใช้ตัวสร้างตัวแยกวิเคราะห์ควรส่งผลให้เกิดบางอย่างO(n)และฉันสงสัยว่าการแยกวิเคราะห์เป็นปัญหาคอขวดในการใช้เครื่องมือมาก