पीवीएस-स्टूडियो बनाम क्लैंग

हमने अकस्मात क्लैंग परियोजना की जाँच की। मुझे लगता है कि परिणाम कई डेवलपर्स के लिए दिलचस्प होगा। कट के तहत विवरण।

PVS-Studio अब एक बाहरी Microsoft Visual C ++ प्रीप्रोसेसर का उपयोग करता है, जो एक महत्वपूर्ण कमी है। विजुअल C ++ प्रीप्रोसेसर बेहद धीमा है और इसमें त्रुटियाँ हैं जिन्हें हम ठीक नहीं कर सकते हैं। हां, यह आपको आश्चर्यचकित नहीं करता है कि प्रीप्रोसेसर बुरी तरह से काम करता है, लेकिन यह आपको विजुअल स्टूडियो में फाइलों को जल्दी और सही तरीके से संकलित करने से नहीं रोकता है। मुझे ठीक-ठीक पता नहीं है कि cl.exe की व्यवस्था कैसे की जाती है, लेकिन अप्रत्यक्ष साक्ष्यों से मैं यह मान सकता हूं कि * .i फ़ाइलों को संकलित करने और बनाने के लिए उपयोग किए जाने वाले दो पूरी तरह से अलग-अलग प्रीप्रोसेसिंग एल्गोरिदम हैं। जाहिर है, यह संकलक वास्तुकला के संदर्भ में अधिक सुविधाजनक है।

हाल ही में, हम सक्रिय रूप से फ़ाइल प्रीप्रोसेसिंग के लिए वैकल्पिक समाधान की तलाश में हैं। और जाहिर है, हमारी पसंद क्लैंग में लागू प्रीप्रोसेसर पर ध्यान केंद्रित करेगी। प्रारंभिक माप बताते हैं कि यह cl.exe की तुलना में कई गुना तेजी से काम करता है, जो बहुत अच्छा और उपयोगी है।

क्लैंग सी जैसी भाषाओं (C, C ++, Objective-C, Objective-C ++, C ++ 11 के लिए प्रोसेस सपोर्ट में) के लिए एक नया संकलक है। विकास Apple द्वारा प्रायोजित है। क्लैंग कंपाइलर की ताकत में से एक स्थिर कोड विश्लेषण के लिए बड़ी संख्या में नियम हैं। व्यवहार में, क्लैंग पहले से ही एप्पल द्वारा एक स्थिर विश्लेषण उपकरण के रूप में उपयोग किया जाता है।

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

तो, अच्छे के लिए, पीवीएस-स्टूडियो, शायद, क्लैंग पर आधारित होना चाहिए, न कि विवाकोर [2] पर। लेकिन अब बहुत देर हो चुकी है और सब कुछ इतना स्पष्ट नहीं है। इस मामले में, हम तीसरे पक्ष के पुस्तकालय की क्षमताओं पर बहुत अधिक निर्भर करेंगे। और वे क्लैंग प्रोजेक्ट में Microsoft विशिष्ट का समर्थन करने के लिए कोई जल्दी नहीं हैं।

हालाँकि, हम विचलित थे। किसी अन्य कोड विश्लेषक के साथ एक कोड विश्लेषक की जांच करना सबसे दिलचस्प है। हमने ऐसा किया, क्योंकि हम पहले से ही क्लैंग परियोजना का अध्ययन करना शुरू कर चुके थे।

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

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

आइए देखें कि हमें क्या दिलचस्प लगा। लगभग सभी त्रुटियां कॉपी-पेस्ट त्रुटियां हैं।

त्रुटि कॉपी-पेस्ट N १

static SDValue PerformSELECTCombine(...) { ... SDValue LHS = N->getOperand(1); SDValue RHS = N->getOperand(2); ... if (!UnsafeFPMath && !DAG.isKnownNeverZero(LHS) && !DAG.isKnownNeverZero(RHS)) ... if (!UnsafeFPMath && !DAG.isKnownNeverZero(LHS) && !DAG.isKnownNeverZero(LHS)) ... } 

PVS-Studio डायग्नोस्टिक्स: V501 समान उप-अभिव्यक्तियाँ हैं! 'DAG.isKnownNeverZero (LHS)' बाईं ओर और '&&' ऑपरेटर के दाईं ओर स्थित हैं। LLVMX86CodeGen x86isellowering.cpp 11635

शुरुआत में, कोड एक साथ LHS और RHS के साथ काम करता है, और उसके बाद केवल LHS के साथ। इसका कारण, जाहिरा तौर पर, एक लाइन का टाइपो या कॉपी किया हुआ टुकड़ा था। जैसा कि मैं इसे समझता हूं, दूसरे मामले में, आरएचएस चर भी मौजूद होना चाहिए।

त्रुटि कॉपी-पेस्ट N2

 MapTy PerPtrTopDown; MapTy PerPtrBottomUp; void clearBottomUpPointers() { PerPtrTopDown.clear(); } void clearTopDownPointers() { PerPtrTopDown.clear(); } 

PVS-Studio Diagnostics: V524 यह अजीब है कि 'ClearTopDownPointers' फ़ंक्शन का शरीर 'ClearBottomUpPointers' फ़ंक्शन (ObjCARC.cpp, पंक्ति 718) के शरीर के पूरी तरह से समकक्ष है। LLVMScalarOpts objcarc.cpp 1322

क्लासिक कॉपी-पेस्ट। फ़ंक्शन की प्रतिलिपि बनाई गई है। उसका नाम बदल दिया गया, लेकिन शरीर ही नहीं। सही विकल्प:

 void clearBottomUpPointers() { PerPtrBottomUp.clear(); } 

त्रुटि कॉपी-पेस्ट N3

 static Value *SimplifyICmpInst(...) { ... case Instruction::Shl: { bool NUW = LBO->hasNoUnsignedWrap() && LBO->hasNoUnsignedWrap(); bool NSW = LBO->hasNoSignedWrap() && RBO->hasNoSignedWrap(); ... } 

PVS-Studio डायग्नोस्टिक्स: V501 समान उप-अभिव्यक्तियाँ हैं 'LBO-> hasNoUnsignedWrap ()' बाईं ओर और '&&' ऑपरेटर के दाईं ओर है। एलएलवीएमएनालिसिस निर्देशिमिपुलाइज़। सीसी 1891

जाहिर है, वे इस तरह लिखना चाहते थे:

 bool NUW = LBO->hasNoUnsignedWrap() && RBO->hasNoUnsignedWrap(); 

कॉपी-पेस्ट N4 त्रुटि

 Sema::DeduceTemplateArguments(...) { ... if ((P->isPointerType() && A->isPointerType()) || (P->isMemberPointerType() && P->isMemberPointerType())) ... } 

पीवीएस-स्टूडियो के निदान। V501 समान उप-अभिव्यक्तियाँ हैं 'P-> isMemberPointerType ()' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। clangSema sematemplatededuction.cpp 3240

यह केवल एक मामला है, पांचवें उदाहरण के विपरीत। यह स्पष्ट है कि वे इस तरह लिखना चाहते थे:

(P-> isMemberPointerType () और& A-> isMemberPointerType ())

कॉपी-पेस्ट N5 त्रुटि

 static bool CollectBSwapParts(...) { ... // 2) The input and ultimate destinations must line up: if byte 3 of an i32 // is demanded, it needs to go into byte 0 of the result. This means that the // byte needs to be shifted until it lands in the right byte bucket. The // shift amount depends on the position: if the byte is coming from the high // part of the value (eg byte 3) then it must be shifted right. If from the // low part, it must be shifted left. unsigned DestByteNo = InputByteNo + OverallLeftShift; if (InputByteNo < ByteValues.size()/2) { if (ByteValues.size()-1-DestByteNo != InputByteNo) return true; } else { if (ByteValues.size()-1-DestByteNo != InputByteNo) return true; } ... } 

PVS-Studio डायग्नोस्टिक्स: V523 '' तो 'स्टेटमेंट' और 'स्टेटमेंट के बराबर है। LLVMInstCombine instcombineandorxor.cpp 1387

और यह एक कठिन परिस्थिति का उदाहरण है। यहां तक ​​कि त्रुटि के अंत तक मुझे भी यकीन नहीं है कि नहीं। कमेंट्री मेरी कोई मदद नहीं करती है। यहाँ, रचनाकारों को कोड का विश्लेषण करना चाहिए। लेकिन फिर भी, मुझे लगता है कि यहां कॉपी-पेस्ट के साथ त्रुटि का एक उदाहरण है।

मुझे लगता है कि कॉपी-पेस्ट के बारे में अभी काफी है, क्योंकि कई अन्य प्रकार की त्रुटियां हैं।

यहां, उदाहरण के लिए, स्विच में एक क्लासिक त्रुटि है

 void llvm::EmitAnyX86InstComments(...) { ... case X86::VPERMILPSri: DecodeVPERMILPSMask(4, MI->getOperand(2).getImm(), ShuffleMask); Src1Name = getRegName(MI->getOperand(0).getReg()); case X86::VPERMILPSYri: DecodeVPERMILPSMask(8, MI->getOperand(2).getImm(), ShuffleMask); Src1Name = getRegName(MI->getOperand(0).getReg()); break; ... } 

PVS-Studio डायग्नोस्टिक्स: V519 'Src1Name' वेरिएबल को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 211, 215. LLVMX86AsmPrinter x86instcomments.cpp 215

बड़े कोड में, ऐसी त्रुटियां बस अपरिहार्य हैं। स्विच स्टेटमेंट बहुत खतरनाक है। आप जितना चाहें उतना जान सकते हैं कि यह कैसे काम करता है, लेकिन फिर भी आप इस लानत को 'तोड़' सकते हैं।

कई संख्याएँ हैं, यदि गलतियाँ नहीं हैं, तो स्पष्ट रूप से मूर्खतापूर्ण या संदिग्ध कार्य हैं।

मूर्खतापूर्ण कार्रवाई N1, जो एक गलती हो सकती है

 AsmToken AsmLexer::LexLineComment() { // FIXME: This is broken if we happen to a comment at the end of a file, which // was .included, and which doesn't end with a newline. int CurChar = getNextChar(); while (CurChar != '\n' && CurChar != '\n' && CurChar != EOF) CurChar = getNextChar(); ... } 

डायग्नोस्टिक्स PVS-Studio: V501 बाईं और '&&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: CurChar! = '\ N' && CurChar! = '\' N 'LLVMMINARser asmlexer.cpp 149!

सबसे अधिक संभावना है, दूसरा कर्चर! = '\ N' चेक यहां अनावश्यक है। लेकिन शायद यह एक गलती है और लिखा जाना चाहिए:

 while (CurChar != '\n' && CurChar != '\r' && CurChar != EOF) 

N2 की मूर्खतापूर्ण कार्रवाई, जो निश्चित रूप से गलती नहीं है

 std::string ASTContext::getObjCEncodingForBlock(const BlockExpr *Expr) const { ... ParmOffset = PtrSize; // Argument types. ParmOffset = PtrSize; ... } 

पीवीएस-स्टूडियो डायग्नोस्टिक्स: वी 519 'परमोफसेट' वेरिएबल को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 3953, 3956। clangAST astcontext.cpp 3956

एन 3 की बेवकूफाना कार्रवाई, जिसे मुझे वर्णन करना मुश्किल है

 static unsigned getTypeOfMaskedICmp(...) { ... result |= (icmp_eq ? (FoldMskICmp_Mask_AllZeroes | FoldMskICmp_Mask_AllZeroes | FoldMskICmp_AMask_Mixed | FoldMskICmp_BMask_Mixed) : (FoldMskICmp_Mask_NotAllZeroes | FoldMskICmp_Mask_NotAllZeroes | FoldMskICmp_AMask_NotMixed | FoldMskICmp_BMask_NotMixed)); ... } 

पीवीएस-स्टूडियो डायग्नोस्टिक्स:

V501 समान उप-अभिव्यक्तियाँ हैं 'FoldMskICmp_Mask_AllZeroes' बाईं और दाईं ओर '|' ऑपरेटर। LLVMInstCombine instcombineandorxor.cpp 505

V501 समान उप-अभिव्यक्तियाँ हैं 'FoldMskICmp_Mask_NotAllZeroes' बाईं और दाईं ओर '| ऑपरेटर। LLVMInstCombine instcombineandorxor.cpp 509

मुझे नहीं पता कि ये सरल डुप्लिकेट हैं या यदि एक अलग स्थिति लिखी जानी चाहिए। यह मान लेना मुश्किल है कि यह वास्तव में यहां होना चाहिए।

वहाँ कोड है कि बस संभावित रूप से खतरनाक है।

यह कोड तब तक काम करेगा जब तक कि दो एनुम में एक समान संरचना न हो।

 enum LegalizeAction { Legal, // The target natively supports this operation. Promote, // This operation should be executed in a larger type. Expand, // Try to expand this to other ops, otherwise use a libcall. Custom // Use the LowerOperation hook to implement custom lowering. }; enum LegalizeTypeAction { TypeLegal, // The target natively supports this type. TypePromoteInteger, // Replace this integer with a larger one. TypeExpandInteger, // Split this integer into two of half the size. ... }; LegalizeTypeAction getTypeAction(LLVMContext &Context, EVT VT) const; EVT getTypeToExpandTo(LLVMContext &Context, EVT VT) const { ... switch (getTypeAction(Context, VT)) { case Legal: return VT; case Expand: ... } 

पीवीएस-स्टूडियो डायग्नोस्टिक्स:

V556 विभिन्न एनम प्रकारों के मूल्यों की तुलना की जाती है: स्विच (ENUM_TYPE_A) {मामला ENUM_TYPE_B: ...}। LLVMAsmPrinter targetlowering.h 268

V556 विभिन्न एनम प्रकारों के मूल्यों की तुलना की जाती है: स्विच (ENUM_TYPE_A) {मामला ENUM_TYPE_B: ...}। LLVMAsmPrinter targetlowering.h 270

TypeLegal का होना कानूनी के साथ समान है, और TypeExpandInteger का नाम विस्तार के साथ व्यंजन है। यही कारण था टाइपो का। कोड केवल इसलिए काम करता है क्योंकि यह भाग्यशाली है और इन नामों के मूल्य मेल खाते हैं।

निष्कर्ष

डरावना जब संकलक में त्रुटियां हैं? :)

पुनश्च

मुझे लगता है कि मैंने क्लैंग की प्रशंसा करना जल्दबाजी की। बस एक ऐसी स्थिति पर ठोकर खाई जहां प्रीप्रोसेसिंग के दौरान यह कोड को खराब करता है। हम इस टुकड़े atlcore.h में है:

 ATLASSUME(p != NULL); // Too expensive to check separately here if (*p == '\0') // ::CharNextA won't increment if we're at a \0 already return const_cast<_CharType*>(p+1); 

क्लैंग प्रीप्रोसेसर इस में बदल जाता है:

 do { ((void)0); #pragma warning(push) #pragma warning(disable : 4548) do {__noop(!!(p != 0));} while((0,0) #pragma warning(pop) ); } while(0); // Too expensive to check separately here if (*p == '\0') // ::CharNextA won't increment if we're at a \0 already return const_cast<_CharType*>(p+1); 

उन्होंने टिप्पणी के बाद 'अगर' बयान दिया और यह निकला कि "अगर (* p == '\ 0')" अब भी एक टिप्पणी है। परिणामस्वरूप, हमारे पास एक गलत कोड है। एह, प्रोग्रामर के जीवन में कोई खुशी नहीं है।

अतिरिक्त लिंक।

1. विकिपीडिया। बजना। http://www.viva64.com/go.php?url=713
2. VivaCore पुस्तकालय। http://www.viva64.com/ru/vivacore-library/