क्लैंग और आईडीई: दोस्ती और दोस्ती के बारे में एक कहानी

मेरे लिए, यह साढ़े छह साल पहले शुरू हुआ था, जब भाग्य की इच्छा से, मुझे एक बंद परियोजना में शामिल किया गया था। किसका प्रोजेक्ट है - मत पूछो, मैं नहीं बताऊंगा मैं केवल यह कह सकता हूं कि उनका विचार एक रेक के रूप में सरल था: आईडीई में क्लैंग फ्रंट-एंड एम्बेड करें। खैर, जैसा कि हाल ही में QtCreator में किया गया है, CLion में (एक अर्थ में), आदि। क्लैंग तब एक उभरता हुआ सितारा था, कई लोग पूर्ण सी-सी + पार्सर का लगभग मुफ्त में उपयोग करने की संभावना के आसपास घूम रहे थे। और विचार, इसलिए बोलने के लिए, शाब्दिक रूप से हवा में था (और क्लैंग एपीआई में निर्मित कोड का ऑटोकॉम्पलेट बी द्वारा संकेत दिया गया था), आपको बस इसे लेना और करना था। लेकिन, जैसा कि बोरोमिर ने कहा, "आप इसे नहीं ले सकते, और ..."। तो यह इस मामले में हुआ। विवरण के लिए - बिल्ली के नीचे वेलकम।

पहले अच्छे के बारे में

आईडीई सी ++ में बिल्ट-इन पार्सर के रूप में क्लैंग का उपयोग करने से लाभ, निश्चित रूप से हैं। अंत में, आईडीई फ़ंक्शन केवल संपादन फ़ाइलों तक सीमित नहीं हैं। यह वर्णों, और नेविगेशन कार्यों, और निर्भरता, और बहुत कुछ का एक डेटाबेस है। और यहां एक पूर्ण संकलक अपनी पूरी ऊंचाई तक पहुंचता है, क्योंकि अपेक्षाकृत सरल स्व-लिखित पार्सर में प्रीप्रोसेसर और टेम्प्लेट की सभी शक्ति को प्रबल करना एक तुच्छ कार्य नहीं है। क्योंकि आपको आमतौर पर बहुत सारे समझौते करने पड़ते हैं, जो स्पष्ट रूप से कोड पार्सिंग की गुणवत्ता को प्रभावित करता है। कौन परवाह करता है - QtCeator के बिल्ट-इन पार्सर को यहाँ देख, कह सकता है: Qt क्रिएटर C ++ क्रॉसर

एक ही जगह में, QtCreator के स्रोत कोड में, आप देख सकते हैं कि उपरोक्त वह सब नहीं है जो आईडीई को पार्सर से चाहिए। इसके अलावा, आपको कम से कम चाहिए:

• वाक्य रचना हाइलाइटिंग (लेक्सिकल और सिमेंटिक)
• प्रतीक पर जानकारी के प्रदर्शन के साथ "मक्खी पर" संकेत के सभी प्रकार
• कोड के बारे में क्या गलत है और इसे कैसे ठीक करें / पूरक करें, इसके बारे में संकेत
• विभिन्न संदर्भों में कोड समापन
• सबसे विविध refactoring

इसलिए, पहले से सूचीबद्ध लाभों (वास्तव में गंभीर!) पर, प्लसस समाप्त होता है और दर्द शुरू होता है। इस दर्द को बेहतर ढंग से समझने के लिए, आप सबसे पहले अनास्तासिया कजाकोवा ( अनास्तासी 2525 ) की रिपोर्ट देख सकते हैं कि वास्तव में आईडीई में निर्मित कोड पार्सर से क्या आवश्यक है:

समस्या का सार

लेकिन यह सरल है, हालांकि यह पहली नज़र में स्पष्ट नहीं हो सकता है। संक्षेप में, फिर: क्लैंग एक संकलक है । और कोड को संकलक के रूप में संदर्भित करता है। और इस तथ्य से तेज कि कोड उसे पहले से ही पूरा कर दिया गया है, न कि उस फ़ाइल का स्टब जो अब आईडीआर संपादक में खुला है। कंपाइलर फ़ाइलों के बिट्स को पसंद नहीं करते हैं, जैसे अपूर्ण निर्माण, गलत तरीके से लिखे गए पहचानकर्ता, वापसी के बजाय रिट्रन , और अन्य प्रसन्नता जो यहां और अब संपादक में पैदा हो सकती हैं। बेशक, संकलन से पहले, यह सब साफ हो जाएगा, तय किया जाएगा, लाइन में लाया जाएगा। लेकिन यहां और अब, संपादक में, यह वही है जो यह है। और यह इस रूप में है कि आईडीई में निर्मित पार्सर हर 5-10 सेकंड में टेबल पर पहुंच जाता है। और अगर इसका स्व-लिखित संस्करण पूरी तरह से "समझता है" कि यह एक अर्ध-तैयार उत्पाद के साथ काम कर रहा है, तो क्लैंग - नहीं। और बहुत हैरान हुआ। इस तरह के आश्चर्य के परिणामस्वरूप क्या होता है "पर" निर्भर करता है, जैसा कि वे कहते हैं।

सौभाग्य से, क्लैंग कोड त्रुटियों के प्रति काफी सहिष्णु है। फिर भी, आश्चर्य हो सकता है - अचानक गायब हो जाना, ऑटो-पूर्ण वक्र, अजीब निदान। आपको इस सब के लिए तैयार रहने की जरूरत है। इसके अलावा, क्लैंग सर्वाहारी नहीं है। उन्हें कंपाइलर के हेडर में कुछ भी स्वीकार नहीं करने का अधिकार है, जो यहां और अब प्रोजेक्ट बनाने के लिए उपयोग किया जाता है। मुश्किल आंतरिक, गैर-मानक एक्सटेंशन और अन्य, उम ..., विशेषताएं - यह सब सबसे अप्रत्याशित स्थानों में पार्सिंग त्रुटियों को जन्म दे सकता है। और, ज़ाहिर है, प्रदर्शन। Boost.Spirit पर एक व्याकरण फ़ाइल को संपादित करना या एक llvm- आधारित परियोजना पर काम करना एक खुशी होगी। लेकिन, सब कुछ के बारे में अधिक विस्तार से।

पूर्वनिर्मित कोड

तो, मान लीजिए कि आपने एक नई परियोजना शुरू की है। आपका वातावरण main.cpp के लिए एक डिफ़ॉल्ट रिक्त उत्पन्न करता है, और इसमें आपने लिखा है:

#include <iostream> int main() { foo(10) } 

C ++ के दृष्टिकोण से कोड, स्पष्ट रूप से, अमान्य है। फ़ाइल में फ़ंक्शन फू (...) की कोई परिभाषा नहीं है, लाइन पूरी नहीं हुई है, आदि। लेकिन ... आपने अभी शुरू किया है। इस कोड पर इस प्रकार का अधिकार है। यह कोड एक स्व-लिखित पार्सर (इस मामले में CLION) के साथ आईडीई को कैसे दर्शाता है?

और यदि आप प्रकाश बल्ब पर क्लिक करते हैं, तो आप इसे देख सकते हैं:

इस तरह की एक आईडीई, कुछ जानने के लिए, उम, क्या हो रहा है के बारे में अधिक, बहुत अपेक्षित विकल्प प्रदान करता है: उपयोग के संदर्भ से एक फ़ंक्शन बनाने के लिए। महान प्रस्ताव, मुझे लगता है। क्लैंग-आधारित आईडीई कैसे व्यवहार करता है (इस मामले में, क्यूटी निर्माता 4.7)?

और स्थिति को सुधारने के लिए क्या प्रस्तावित किया जा रहा है? लेकिन कुछ भी नहीं! केवल मानक नाम!

इस व्यवहार का कारण बहुत सरल है: क्लैंग के लिए, यह पाठ पूर्ण है (और यह कुछ और नहीं हो सकता है)। और वह इस धारणा के आधार पर एएसटी का निर्माण करता है। और फिर सब कुछ सरल है: क्लैंग पहले से अपरिभाषित पहचानकर्ता को देखता है। यह C ++ में पाठ है (C में नहीं)। पहचानकर्ता की प्रकृति के बारे में कोई धारणा नहीं बनाई गई है - यह परिभाषित नहीं है, इसलिए कोड का एक टुकड़ा अमान्य है। और इस लाइन के लिए एएसटी में कुछ भी नहीं दिखाई देता है। वह अभी नहीं है। और एएसटी में जो नहीं है, उसका विश्लेषण करना असंभव है। यह शर्म की बात है, कष्टप्रद है, ठीक है।

आईडीई में निर्मित पार्सर कुछ अन्य मान्यताओं से आता है। वह जानता है कि कोड समाप्त नहीं हुआ है। यह प्रोग्रामर अभी सोच विचार कर रहा है और उसके पीछे की उंगलियों के पास समय नहीं है। इसलिए, सभी पहचानकर्ताओं को परिभाषित नहीं किया जा सकता है। इस तरह के कोड, संकलक गुणवत्ता के उच्च मानकों के दृष्टिकोण से गलत हैं, लेकिन पार्सर जानता है कि ऐसे कोड के साथ क्या किया जा सकता है और विकल्प प्रदान करता है। उचित विकल्प।

कम से कम जब तक संस्करण 3.7 (समावेशी), इसी तरह की समस्याएं इस कोड में हुईं:

 #include <iostream> class Temp { public: int i; }; template<typename T> class Foo { public: int Bar(Temp tmp) { Tpl(tmp); } private: template<typename U> void Tpl(U val) { Foo<U> tmp(val); tmp. } int member; }; int main() { return 0; } 

टेम्प्लेट क्लास के तरीकों के अंदर, क्लैंग-आधारित ऑटोकॉमप्लेट काम नहीं करता था। जहाँ तक मुझे यह पता लगाने में कामयाब रहा, इसका कारण दो-तरफ़ा पार्सिंग में था। क्लैंग में स्वत: पूर्ण पहले ट्रिगर पर ट्रिगर होता है, जब वास्तव में उपयोग किए जाने वाले प्रकारों के बारे में जानकारी पर्याप्त नहीं हो सकती है। क्लैंग 5.0 (रिलीज नोट्स द्वारा निर्णय लेने) में, यह तय किया गया था।

एक तरीका या दूसरा, ऐसी परिस्थितियाँ जिनमें संकलक संपादित कोड में सही एएसटी का निर्माण करने में सक्षम नहीं है (या संदर्भ से सही निष्कर्ष निकालते हैं) अच्छी तरह से हो सकता है। और इस मामले में, आईडीई बस पाठ के संबंधित वर्गों को "नहीं" देखेगा और किसी भी तरह से प्रोग्रामर की मदद करने में सक्षम नहीं होगा। जो, ज़ाहिर है, महान नहीं है। गलत कोड के साथ प्रभावी ढंग से काम करने की क्षमता आईडीई में पार्सर की जरूरत है, और नियमित कंपाइलर की क्या आवश्यकता है। इसलिए, आईडीई में पार्सर कई हेयूरिस्टिक्स का उपयोग कर सकता है, जो संकलक के लिए न केवल बेकार हो सकता है, बल्कि हानिकारक भी हो सकता है। और इसमें दो ऑपरेटिंग मोड को लागू करने के लिए - ठीक है, आपको अभी भी डेवलपर्स को समझाने की आवश्यकता है।

"यह भूमिका अपमानजनक है!"

प्रोग्रामर की आईडीई आमतौर पर एक (अच्छी तरह से, दो) होती है, लेकिन बहुत सारी परियोजनाएं और टूलचिन हैं। और, ज़ाहिर है, मैं टूलकिन से टूलकिन तक, परियोजना से परियोजना तक स्विच करने के लिए कोई अतिरिक्त इशारे नहीं करना चाहता। एक या दो क्लिक, और बिल्ड कॉन्फ़िगरेशन डीबग से रिलीज़ तक बदलता है, और MSVC से MinGW तक संकलक। लेकिन IDE में कोड पार्सर वही रहता है। और उसे बिल्ड सिस्टम के साथ मिलकर एक कॉन्फ़िगरेशन से दूसरे में, एक टूलकिन से दूसरे में स्विच करना होगा। एक टूलकिन किसी प्रकार का विदेशी, या पार हो सकता है। और यहां पार्सर का कार्य कोड को सही ढंग से पार्स करना जारी रखना है। यदि संभव हो तो कम से कम त्रुटियों के साथ।

क्लैंग सर्वाहारी पर्याप्त है। यह Microsoft से संकलक एक्सटेंशन को स्वीकार करने के लिए मजबूर किया जा सकता है, gcc संकलक। यह इन संकलक के प्रारूप में विकल्प पारित किया जा सकता है, और क्लैंग भी उन्हें समझेंगे। लेकिन यह सब इस बात की गारंटी नहीं है कि क्लच, जीसीसी टैंक से एकत्र किए गए जीबिल से किसी भी शीर्षक को स्वीकार करेगा। कोई भी __builtin_intrinsic_xxx उसके लिए ठोकर बन सकता है। या भाषा निर्माण करती है कि IDE में क्लैंग का वर्तमान संस्करण केवल समर्थन नहीं करता है। सबसे अधिक संभावना है, यह वर्तमान में संपादित फ़ाइल के लिए एएसटी निर्माण की गुणवत्ता को प्रभावित नहीं करेगा। लेकिन एक वैश्विक चरित्र आधार का निर्माण या पूर्वनिर्मित हेडर को बचाने से टूट सकता है। और यह एक गंभीर समस्या हो सकती है। इसी तरह की समस्या टूलचिन्स या थर्डपार्टी के हेडर में नहीं, बल्कि प्रोजेक्ट के हेडर या सोर्स कोड में समान कोड हो सकती है। वैसे, यह सब निर्माण प्रणाली (और आईडीई) को स्पष्ट रूप से बताने के लिए एक महत्वपूर्ण पर्याप्त कारण है जिसके बारे में आपकी परियोजना के लिए हेडर फाइलें "एलियन" हैं। यह जीवन को आसान बना सकता है।

फिर से, आईडीई को मूल रूप से विभिन्न संकलक, सेटिंग्स, टूलचिन और अधिक के साथ उपयोग करने के लिए डिज़ाइन किया गया था। कोड से निपटने के लिए डिज़ाइन किया गया है, जिनके कुछ तत्व समर्थित नहीं हैं। IDE का रिलीज़ चक्र (सभी नहीं :)) संकलक की तुलना में छोटा है, इसलिए, नई सुविधाओं को और अधिक तेज़ी से खींचने और मिली समस्याओं का जवाब देने की क्षमता है। संकलक की दुनिया में, सब कुछ थोड़ा अलग है: रिलीज चक्र कम से कम एक वर्ष है, क्रॉस-कंपाइलर संगतता की समस्याओं को सशर्त संकलन द्वारा हल किया जाता है और डेवलपर के कंधों पर पारित किया जाता है। संकलक को सार्वभौमिक और सर्वव्यापी होने की आवश्यकता नहीं है - इसकी जटिलता पहले से ही उच्च है। क्लैंग कोई अपवाद नहीं है।

गति के लिए लड़ाई

आईडीई में बिताए समय का वह हिस्सा, जब प्रोग्रामर डिबगर में नहीं बैठा होता है, तो वह पाठ को संपादित करता है। और यहां उनकी स्वाभाविक इच्छा इसे सहज बनाने की है (अन्यथा एक आईडीई क्यों? क्या मैं नोटपैड के साथ मिल सकता हूं?) आराम, विशेष रूप से, पाठ परिवर्तनों और हॉटकीज़ को दबाने पर संपादक की उच्च गति की प्रतिक्रिया शामिल है। जैसा कि अनास्तासिया ने अपनी रिपोर्ट में सही ढंग से नोट किया है, अगर Ctrl + Space दबाने के पांच सेकंड बाद वातावरण ने मेनू या स्वतः पूर्ण की सूची के साथ प्रतिक्रिया नहीं दी, तो यह भयानक है (गंभीरता से, इसे स्वयं आज़माएं)। संख्याओं में, इसका मतलब है कि आईडीई में निर्मित पार्सर के पास फ़ाइल में परिवर्तनों का मूल्यांकन करने और एएसटी के पुनर्निर्माण के लिए लगभग एक सेकंड है, और डेवलपर को संदर्भ-संवेदनशील विकल्प प्रदान करने के लिए एक और डेढ़ या दो हैं। दूसरा। खैर, शायद दो। इसके अलावा, अपेक्षित व्यवहार यह है कि यदि डेवलपर ने .h-निकनेम को बदल दिया है, और फिर .cpp-shnik पर स्विच कर दिया है, तो किए गए परिवर्तन "दृश्यमान" होंगे। फाइलें, यहां वे हैं, पड़ोसी की खिड़कियों में खोली गई हैं। और अब एक साधारण गणना। यदि कमांड लाइन से लॉन्च किया गया क्लैंग, स्रोत कोड के साथ लगभग दस से बीस सेकंड में सामना कर सकता है, तो यह मानने का कारण कहां है कि जब आईडीई से लॉन्च किया गया तो यह स्रोत कोड के साथ बहुत तेजी से सामना करेगा और उस दूसरे या दो में फिट होगा? यही है, यह तेजी से परिमाण के एक आदेश पर काम करेगा? सामान्य तौर पर, यह समाप्त हो सकता है, लेकिन मैं नहीं करूंगा।

स्रोत के बारे में दस से बीस सेकंड, ज़ाहिर है, मैं अतिशयोक्ति करता हूं। हालाँकि, अगर कुछ भारी एपीआई वहाँ शामिल है या, कहते हैं, बढ़ावा दें। तैयार पर हाना के साथ, और फिर यह सब पाठ में सक्रिय रूप से उपयोग किया जाता है, फिर भी 10-20 सेकंड अच्छे मूल्य हैं। लेकिन भले ही एएसटी बिल्ट-इन पार्सर के लॉन्च के तीन या चार बाद तैयार हो - यह पहले से ही एक लंबा समय है। बशर्ते कि इस तरह के लॉन्च नियमित रूप से होने चाहिए (एक सुसंगत स्थिति में कोड मॉडल और सूचकांक को बनाए रखने के लिए, हाइलाइट, प्रॉम्प्ट, आदि), साथ ही मांग पर - कोड पूरा होने पर भी कंपाइलर का लॉन्च होता है। क्या किसी तरह इस समय को कम करना संभव है? दुर्भाग्य से, क्लैंगर को एक पार्सर के रूप में उपयोग करने के मामले में, कई संभावनाएं नहीं हैं। कारण: यह एक थर्डपार्टी टूल है जिसमें ( आदर्श रूप से ) बदलाव नहीं किए जा सकते हैं। यही है, परिधीय के साथ क्लैंग कोड में खुदाई करना, अनुकूलन करना, कुछ शाखाओं को सरल बनाना - ये सुविधाएं उपलब्ध नहीं हैं और आपको बाहरी एपीआई प्रदान करने के साथ क्या करना है (कामेच्छा का उपयोग करने के मामले में, यह भी काफी संकीर्ण है)।

पहला, स्पष्ट और, वास्तव में, एकमात्र समाधान गतिशील रूप से उत्पन्न पूर्व-निर्मित हेडर का उपयोग करना है। पर्याप्त कार्यान्वयन के साथ, समाधान हत्यारा है। कम से कम कई बार संकलन की गति बढ़ाता है। इसका सार सरल है: पर्यावरण एक एकल .h फ़ाइल में सभी थर्डपार्टी-हेडर (या प्रोजेक्ट रूट के बाहर हेडर) एकत्र करता है, इस फ़ाइल से pch बनाता है, और फिर प्रत्येक स्रोत में इस pch को सम्मिलित करता है। बेशक, एक स्पष्ट दुष्प्रभाव दिखाई देता है: स्रोत कोड में ( संपादन चरण में ), प्रतीकों को देखा जा सकता है जो इसमें शामिल नहीं हैं। लेकिन यह गति के लिए एक शुल्क है। मुझे चुनना है। और सब कुछ ठीक होगा, अगर एक छोटी सी समस्या के लिए नहीं: क्लैंग अभी भी एक संकलक है। और, एक संकलक होने के नाते, वह कोड में त्रुटियों को पसंद नहीं करता है। और अगर अचानक (अचानक! ​​- पिछले अनुभाग को देखें) हेडर में त्रुटियां हैं, तो .pch फ़ाइल नहीं बनाई गई है। कम से कम यह संस्करण 3.7 तक सही था। तब से इस संबंध में कुछ भी बदल गया है? मुझे नहीं पता, इसमें संदेह है कि नहीं। काश, अब जाँच का कोई अवसर नहीं है।

वैकल्पिक विकल्प, अफसोस, एक ही कारण के लिए उपलब्ध नहीं हैं: क्लैंग एक संकलक और एक "अपने आप में" चीज है। एएसटी पीढ़ी प्रक्रिया में सक्रिय रूप से हस्तक्षेप करते हैं, किसी तरह इसे अलग-अलग टुकड़ों से एएसटी मर्ज करते हैं, बाहरी प्रतीक ठिकानों को बनाए रखते हैं और ते और ते - अलस, ये सभी सुविधाएं उपलब्ध नहीं हैं। केवल बाहरी एपीआई, केवल कट्टर और सेटिंग्स संकलन विकल्पों के माध्यम से उपलब्ध है। और फिर परिणामस्वरूप एएसटी का विश्लेषण। यदि आप एपीआई के सी ++ - संस्करण पर बैठते हैं, तो थोड़ा और अवसर उपलब्ध हो जाता है। उदाहरण के लिए, आप कस्टम फ़्रंटएंडएक्शन के साथ खेल सकते हैं, संकलन विकल्पों के लिए बारीक सेटिंग्स कर सकते हैं, आदि लेकिन इस मामले में, मुख्य बिंदु नहीं बदलेगा - संपादित (या अनुक्रमित) पाठ दूसरों के स्वतंत्र रूप से और पूरी तरह से संकलित किया जाएगा। वह सब है। बिंदु।

शायद (शायद!) किसी दिन आईडीई के हिस्से के रूप में उपयोग के लिए विशेष रूप से सिलवाया गया अपस्ट्रीम क्लैंग का कांटा होगा। हो सकता है कि। लेकिन अभी के लिए, सब कुछ वैसा ही है जैसा कि है। Qt क्रिएटर की टीम के एकीकरण ("अंतिम" चरण में) को लिबरक्लैंग के साथ सात साल हो गए। मैंने एक libclang- आधारित इंजन के साथ QtC 4.7 की कोशिश की - मैं मानता हूं, मैं व्यक्तिगत रूप से पुराने संस्करण (स्व-लिखित एक पर) को अधिक सरलता से पसंद करता हूं क्योंकि यह मेरे मामलों पर बेहतर काम करता है: यह संकेत देता है और हाइलाइट करता है, और बाकी सब। मैं यह अनुमान लगाने में कोई कसर नहीं छोड़ूंगा कि उन्होंने इस एकीकरण पर कितने मानव घंटे बिताए, लेकिन मैं यह सुझाव देने के लिए उद्यम करता हूं कि इस समय के दौरान मेरे खुद के पार्सर को खत्म करना संभव होगा। जहां तक ​​मैं बता सकता हूं (अप्रत्यक्ष संकेत द्वारा), सीएलआईएन पर काम करने वाली टीम लिबक्लैंग / क्लैंग ++ के साथ एकीकरण की ओर सतर्कता से देखती है। लेकिन ये विशुद्ध रूप से व्यक्तिगत धारणाएं हैं। भाषा सर्वर प्रोटोकॉल स्तर पर एकीकरण एक दिलचस्प विकल्प है, लेकिन विशेष रूप से सी ++ मामले के लिए, मैं ऊपर सूचीबद्ध कारणों के लिए इसे एक उपशामक के रूप में अधिक विचार करता हूं। यह बस एक स्तर से दूसरे स्तर पर समस्याओं को स्थानांतरित करता है। लेकिन शायद मैं LSP - भविष्य के लिए गलत हूँ। आइए देखते हैं। लेकिन वैसे भी, सी ++ के लिए आधुनिक आईडीई के डेवलपर्स का जीवन रोमांच से भरा है - एक बैकएंड के रूप में, या इसके बिना।