🔬 👨🏾‍🚀 👨🏾‍🎨 Clang API। शुरुआत 🈸 🔝 ➖

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

1. क्लैंग या क्लैंग-सी?

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

1.1 क्लैंग-सी एपीआई

क्लैंग सोर्स ट्री में, इस लाइब्रेरी का कार्यान्वयन उपकरण शाखा में स्थित है (क्लैंग कोर का क्रियान्वयन स्वयं लिबास में स्थित है)। इस लाइब्रेरी को गतिशील रूप से लोड किए गए मॉड्यूल में संकलित किया गया है, और इसका इंटरफ़ेस क्लाइंट को कई गारंटी प्रदान करता है:

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

लेकिन, सूचीबद्ध लाभों के लिए आपको भुगतान करना होगा। इसलिए, क्लैंग-सी एपीआई में कमियां हैं:

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

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

1.2 क्लेंग एपीआई

एपीआई का यह संस्करण अनिवार्य रूप से कंपाइलर कोर का इंटरफ़ेस है। यह API विशुद्ध रूप से C ++ है, और यह क्लैंग कर्नेल की सभी विशेषताओं तक विस्तृत पहुँच प्रदान करता है। इसके लाभों में शामिल हैं:

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

और, आंशिक रूप से, नुकसान:

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

कमियां कितनी महत्वपूर्ण हैं, और क्या वे फायदे से बाहर हैं - यह स्थिति के अनुसार तय करना आवश्यक है। मेरी राय में, क्लैंग का उपयोग करने के इस विकल्प को हर जगह चुना जाना चाहिए, इसे अच्छे प्रदर्शन या विशिष्ट विशेषताओं तक पहुंच की आवश्यकता होती है जो क्लैंग-सी के माध्यम से उपलब्ध नहीं हैं। विशेष रूप से, जब IDE के लिए ऑन-द-फ्लाई-पार्सर के रूप में क्लैंग का उपयोग करते हैं, तो यह विशेष एपीआई संस्करण का उपयोग करने के लिए समझ में आता है।

2. आरंभ करना, या स्रोत पाठ को पार्स करना

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

2.1 क्लैंग-सी के साथ पार्सिंग

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

#include <iostream> #include <clang-c/Index.h> int main (int argc, char** argv) { CXIndex index = clang_createIndex ( false, // excludeDeclarationFromPCH true // displayDiagnostics ); CXTranslationUnit unit = clang_parseTranslationUnit ( index, // CIdx "main.cpp", // source_filename argv + 1 , // command_line_args argc - 1 , // num_command_line_args 0, // unsave_files 0, // num_unsaved_files CXTranslationUnit_None // options ); if (unit != 0 ) std::cout << "Translation unit successfully created" << std::endl; else std::cout << "Translation unit was not created" << std::endl; clang_disposeTranslationUnit(unit); clang_disposeIndex(index); }

पहली विधि ( clang_createIndex ) एक संदर्भ बनाती है जिसके भीतर अनुवाद इकाइयों ( CXTranslationUnit ) के उदाहरण बनाए जाएंगे और पार्स किए जाएंगे। यह दो पैरामीटर लेता है। पहला ( बहिष्कृत ) FromPCH परिणामी एएसटी के क्रॉल के दौरान पहले से तैयार हेडर से पढ़े गए विज्ञापनों की दृश्यता को नियंत्रित करता है। 1 के मान का अर्थ है कि ऐसे विज्ञापनों को अंतिम एएसटी से बाहर रखा जाएगा। दूसरा पैरामीटर ( displayDiagnostics ) प्रसारण के दौरान प्राप्त डायग्नोस्टिक्स के आउटपुट को कंसोल पर नियंत्रित करता है।
दूसरी विधि ( clang_parseTranslationUnit ) स्रोत फ़ाइल को ही पार्स करती है। इस विधि में निम्नलिखित पैरामीटर हैं:

CIdx clang_createIndex पर कॉल करके बनाए गए संदर्भ का एक संकेतक है।
source_filename - पार्स करने के लिए फ़ाइल का पथ।
command_line_args - कमांड लाइन तर्क जो संकलक विकल्पों में परिवर्तित हो जाएंगे।
num_command_line_args - पिछले पैरामीटर के रूप में पारित कमांड लाइन पर तर्कों की संख्या।
unsaved_files - फाइलों का एक संग्रह, जिनकी वास्तविक सामग्री स्मृति में है, डिस्क पर नहीं।
num_unsaved_files - अनकॉर्डेड फ़ाइलों के संग्रह में तत्वों की संख्या।
विकल्प - अतिरिक्त पार्सिंग विकल्प।

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

CXTranslationUnit_None - यहां सब कुछ स्पष्ट है। कोई विशेष पार्सिंग विकल्प निर्धारित नहीं हैं।
CXTranslationUnit_DetailedPreprocessingRecord - इस विकल्प को सेट करने से संकेत मिलता है कि स्रोत पाठ में प्रीप्रोसेसर का उपयोग कैसे और कहाँ किया गया है, इस बारे में पार्सर को विस्तृत जानकारी उत्पन्न करनी चाहिए। जैसा कि प्रलेखन दिखाता है, शायद ही कभी इस्तेमाल किया गया विकल्प बड़ी मात्रा में मेमोरी की खपत की ओर जाता है, और यह केवल उन मामलों में इसे स्थापित करने के लायक है जहां ऐसी जानकारी की वास्तव में आवश्यकता होती है।
CXTranslationUnit_Incomplete - इस विकल्प को सेट करना इंगित करता है कि अपूर्ण ( अपूर्ण ) अनुवाद इकाई संसाधित की जा रही है। उदाहरण के लिए, एक हेडर फ़ाइल। इस मामले में, अनुवादक प्रसारण समाप्त होने से पहले उन पैटर्नों को इंस्टेंट करने की कोशिश नहीं करेगा, जिन्हें इंस्टेंट करना होगा।
CXTranslationUnit_PrecompiledPreamble - इस विकल्प को सेट करना इंगित करता है कि पार्सर को स्वचालित रूप से सभी हेडर फ़ाइलों के लिए एक पूर्वनिर्धारित हेडर बनाना चाहिए जो अनुवाद इकाई की शुरुआत में शामिल हैं। यह विकल्प उपयोगी है यदि फ़ाइल को बार-बार बदला जाएगा (clang_reparseTranslationUnit विधि का उपयोग करके), लेकिन इसकी अपनी विशेषताओं के साथ, जिसे अगले अनुभाग में वर्णित किया जाएगा।
CXTranslationUnit_CacheCompletionResults - इस विकल्प की स्थापना इस तथ्य की ओर ले जाती है कि प्रत्येक बाद के पुनरावर्तन के बाद, कोड पूरा होने के परिणामों का हिस्सा सहेजा जाएगा।
CXTranslationUnit_SkipFunctionBodies - इस विकल्प को सेट करने से तथ्य यह होता है कि अनुवाद प्रक्रिया के दौरान कार्यों और विधियों के निकायों पर कार्रवाई नहीं की जाएगी। कुछ पात्रों की घोषणाओं और परिभाषाओं की त्वरित खोज के लिए उपयोगी है।

फ्लैग को '|' ऑपरेशन के उपयोग से जोड़ा जा सकता है।

पिछले दो तरीके ( clang_disposeTranslationUnit और clang_disposeIndex ) पहले बनाए गए हैंडल को हटाते हैं जो अनुवाद इकाई और संदर्भ का वर्णन करते हैं।
इस नमूना कोड को सफलतापूर्वक बनाने के लिए, बस libclang लाइब्रेरी को कनेक्ट करें।

2.1 क्लैंग एपीआई के साथ पार्सिंग

क्लैंग एपीआई का उपयोग करने वाला एक समान (कार्यक्षमता में) कोड इस प्रकार है:

 #include <vector> #include <iostream> #include <clang/Basic/Diagnostic.h> #include <clang/Frontend/DiagnosticOptions.h> #include <clang/Frontend/CompilerInstance.h> #include <clang/Frontend/CompilerInvocation.h> #include <clang/Frontend/Utils.h> #include <clang/Frontend/ASTUnit.h> int main(int argc, char ** argv) { using namespace clang ; using namespace llvm ; // Initialize compiler options list std::vector< const char *> args; for (int n = 1; n < argc; ++ n) args.push_back(argv[n]); args.push_back("main_clang.cpp" ); const char** opts = &args.front(); int opts_num = args.size(); // Create and setup diagnostic consumer DiagnosticOptions diagOpts; IntrusiveRefCntPtr< DiagnosticsEngine> diags(CompilerInstance::createDiagnostics( diagOpts, // Opts opts_num, // Argc opts, // Argv 0, // Client true, // ShouldOwnClient false // ShouldCloneClient )); // Create compiler invocation IntrusiveRefCntPtr< CompilerInvocation> compInvoke = clang::createInvocationFromCommandLine( makeArrayRef(opts, opts + opts_num), // Args diags // Diags ); if (!compInvoke) { std::cout << "Can't create compiler invocation for given args" ; return -1; } // Parse file clang::ASTUnit *tu = ASTUnit ::LoadFromCompilerInvocation( compInvoke.getPtr(), // CI diags, // Diags false, // OnlyLocalDecls true, // CaptureDiagnostics false, // PrecompilePreamble TU_Complete, // TUKind false // CacheCodeCompletionResults ); if (tu == 0 ) std::cout << "Translation unit was not created" ; else std::cout << "Translation unit successfully created" ; return 0; }

इसमें बहुत अधिक अक्षर हैं, और विधानसभा को पुस्तकालयों के निम्नलिखित सेट के साथ एक नज़र की आवश्यकता होती है: clangLex, clangBasic, clangAST, clangSerialization, clangEdit, clangAnalysis, clangFrontend, clangSriver, clangDriver, clangParse, LLVMCore, LLVMCore , LLVMCore । विंडोज के तहत निर्माण करते समय, आपको advapi32 और shell32 को भी जोड़ना होगा। लेकिन आउटपुट अनावश्यक बाहरी निर्भरता के बिना एक निष्पादन योग्य मॉड्यूल होगा।
उपरोक्त कोड को चार भागों में विभाजित किया जा सकता है:

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

कमांड लाइन तर्कों का संग्रह बनाना

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

डायग्नोस्टिक इंजन बनाना

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

एक संकलक मंगलाचरण बनाना

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

स्रोत पाठ को पार्स करना

यह क्लैंग क्लास के स्थिर तरीकों में से एक को कॉल करके किया जाता है: ASTUnit। ऐसे कई तरीके हैं, उन्हें अलग-अलग परिदृश्यों के लिए तेज किया जाता है। उदाहरण संभव विकल्पों में से एक दिखाता है। इस मामले में, कंपाइलर इंवोकेशन इंस्टेंस को पारसर को पास कर दिया जाता है (पार्सर इसके बाद इसे खुद ही डिलीट कर देगा!), डायग्नोस्टिक इंजन इंस्टेंस (इसका पार्सर अपने आप डिलीट नहीं होगा), और कई पैरामीटर जो पार्सर के व्यवहार को नियंत्रित करते हैं:

OnlyLocalDecls - केवल अनुवाद इकाई से घोषणा की गई थी जिसे अंतिम एएसटी में शामिल किया जाएगा। पीसीएच और संलग्न हेडर फ़ाइलों से घोषणाओं को बाहर रखा जाएगा।
कैप्चरडायग्नॉस्टिक - यह नियंत्रित करता है कि निदान कैसे एकत्र किए जाते हैं। यदि झूठ को इस पैरामीटर के रूप में पारित किया जाता है, तो नैदानिक इंजन बनाते समय निर्दिष्ट किए गए सभी निदान नैदानिक ग्राहक को दिए जाएंगे। अन्यथा, निदान ASTUnit की आंतरिक संरचनाओं में सहेजा जाएगा।
PrecompilePreamble - जैसा कि ऊपर उल्लेख किया गया है, इस विकल्प को सक्षम करने के साथ, पार्सर स्वचालित रूप से स्रोत पाठ में शामिल सभी हेडर के लिए पीसीएच बना देगा। हाँ, वास्तव में। बार-बार पार्सिंग के लिए उपयोगी। लेकिन, जैसा कि यह निकला, कुछ सुखद क्षण नहीं हैं। सबसे पहले, वास्तव में, PCH को पहली बार ASTUnit बनाया जाता है :: परिणामी ASTUnit उदाहरण के लिए रिपेयर विधि कहा जाता है । दूसरे, अगर # ifdef-guards के साथ हेडर फ़ाइल पार्स की गई है, तो, अफसोस, कुछ भी नहीं बनाया जाएगा।
TUKind - अनुवाद इकाई का प्रकार। निम्नलिखित विकल्प यहां संभव हैं:
- TU_Complete - पूर्ण रूप से पूर्ण की गई अनुवाद इकाई को पार्स किया गया है। इस स्थिति में, स्रोत पाठ में उपयोग किए गए टेम्प्लेट के सभी उदाहरणों को अंतिम एएसटी में भी रखा जाएगा।
- TU_Prefix - "अनुवाद इकाई के लिए उपसर्ग" को पार्स किया जाता है, इस मामले में स्रोत पाठ को पूर्ण नहीं माना जाता है।
- TU_Module - कुछ "मॉड्यूल" पार्स किया गया है। यह क्या है - प्रलेखन चुप है।
CacheCodeCompletionResults - कोड पूरा करने के परिणामों को पार्स करने के दौरान कैश किया जाएगा। वास्तव में बाद के कोड के अनुरोधों को पूरा करने में मदद करता है।

3. विकल्पों के सेट में छोटी चाल

मेरे पहले प्रयोगों में (यह घोषणाओं को निकालने के लिए हेडर फ़ाइलों को पार्स कर रहा था) लंबे समय तक मुझे यह समझ में नहीं आया कि पार्सिंग बहुत त्रुटियों के साथ समाप्त क्यों हुई। अंत में, सब कुछ काफी सरल निकला। तो, विकल्प जो उपयोगी हो सकते हैं:

-x भाषा - विशेष प्रकार की फ़ाइल को पार्स करने के लिए निर्दिष्ट करता है। एक समान gcc संकलक विकल्प के साथ संगत।
-dd = standard - वह मानक निर्दिष्ट करता है जिससे स्रोत पाठ मेल खाता है। यह gcc संकलक विकल्पों के साथ संगत है।
-फर-सीमा = एन - एन के लिए अधिकतम संख्या में त्रुटियां हैं जिसके बाद पार्सिंग पूरी हो जाएगी। यदि आप किसी भी त्रुटि को अनदेखा करते हुए फ़ाइल को पार्स करना चाहते हैं, तो एन 0 के बराबर होना चाहिए।
-include <उपसर्ग-फ़ाइल> - फ़ाइल (आमतौर पर हेडर) को निर्दिष्ट करता है जिसे मुख्य फ़ाइल को पार्स करने से पहले पार्स किया जाना चाहिए। सामान्य तौर पर, यह विकल्प मूल रूप से एक PCH हैडर को शामिल करने के लिए होता है, लेकिन जब फ़ाइलों को पार्स करना उपयोगी होता है, उदाहरण के लिए, विभिन्न मैक्रोज़ को परिभाषित करने के लिए।

इस पर, क्लैंग एपीआई के साथ पहले परिचित को पूर्ण माना जा सकता है। आप आधिकारिक वेबसाइट पर clang -c API के बारे में अधिक पढ़ सकते हैं: clang.llvm.org/doxygen/group__CINDEX.html
वहां आप खुद को क्लेग एपीआई कक्षाओं के पूरे पदानुक्रम से परिचित कर सकते हैं। दुर्भाग्य से, प्रलेखन स्वचालित रूप से अपस्ट्रीम क्लैंग से उत्पन्न होता है, इसलिए प्रलेखन के साथ वेबसाइट पर वर्णित कार्यों, उनके सेट आदि के हस्ताक्षर इस या उस रिलीज में प्रस्तुत किए गए लोगों से भिन्न हो सकते हैं।

अगले लेख में मैं बात करूँगा कि आप clang के साथ बनाए गए AST से एक घोषणा वृक्ष कैसे प्राप्त कर सकते हैं।

Clang API। शुरुआत