NoVerify static विश्लेषक में एक किलर सुविधा दिखाई दी है: निरीक्षण का वर्णन करने के लिए एक घोषणात्मक तरीका जिसमें गो प्रोग्रामिंग और कोड संकलन की आवश्यकता नहीं होती है।

आपको साज़िश करने के लिए, मैं आपको एक सरल लेकिन उपयोगी निरीक्षण का विवरण दिखाऊंगा:

/** @warning duplicated sub-expressions inside boolean expression */ $x && $x; 

यह निरीक्षण उन सभी तार्किक && भावों का पता लगाता है जहां बाएं और दाएं ऑपरेंड समान हैं।

NoVerify Go में लिखे गए PHP के लिए एक static विश्लेषक है। आप इसके बारे में लेख " NoVerify: Linter for PHP से VKontakte Team " में पढ़ सकते हैं । और इस समीक्षा में मैं नई कार्यक्षमता के बारे में बात करूंगा और हम इसमें कैसे आए।

आवश्यक शर्तें

जब एक साधारण नई जांच के लिए भी आपको गो पर कोड की कुछ दर्जन लाइनें लिखने की आवश्यकता होती है, तो आप आश्चर्य करना शुरू कर देते हैं: क्या यह संभव है?

गो पर, हमने टाइप इंट्रैक्शन, लिंटर की पूरी पाइपलाइन, मेटाडेटा कैश, और कई अन्य महत्वपूर्ण तत्व लिखे हैं जिनके बिना NoVerify असंभव है। ये घटक अद्वितीय हैं, लेकिन "एक फ़ंक्शन X को तर्क वाई के साथ कॉल करने पर रोक लगाने" जैसे कार्य नहीं करते हैं। बस ऐसे सरल कार्यों के लिए गतिशील नियमों का तंत्र जोड़ा गया है।

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

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

साँचा विवरण भाषा

विवरण भाषा PHP के साथ वाक्यात्मक रूप से संगत है। यह इसके अध्ययन को सरल बनाता है, और यह समान PhpStorm का उपयोग करके नियम फ़ाइलों को संपादित करना भी संभव बनाता है।

नियम फ़ाइल की बहुत शुरुआत में, अपने पसंदीदा आईडीई को एक सुखदायक निर्देश सम्मिलित करने की सिफारिश की जाती है:

 <?php /** *      , *        PHP-. * * @noinspection ALL */ // ...  —   . 

टेम्पलेट्स के लिए सिंटैक्स और संभावित फिल्टर के साथ मेरा पहला प्रयोग phpgrep था। यह अपने आप उपयोगी हो सकता है, लेकिन NoVerify के अंदर यह और भी दिलचस्प हो गया है, क्योंकि अब इसमें टाइप जानकारी तक पहुंच है।

मेरे कुछ सहयोगियों ने पहले ही अपने काम में phpgrep की कोशिश की है, और यह सिर्फ इस तरह के सिंटैक्स को चुनने के पक्ष में एक और तर्क था।

Phpgrep अपने आप में PHP के लिए एक gogrep अनुकूलन है (आप cgrep में भी दिलचस्पी ले सकते हैं )। इस प्रोग्राम का उपयोग करके, आप सिंटैक्स टेम्प्लेट के माध्यम से कोड खोज सकते हैं।

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

 PHP-like Lisp-like ----------------------------- $x = $y | (expr = $x $y) fn($x, 1) | (expr call fn $x 1)          : (or (expr == (type string (expr)) (expr)) (expr == (expr) (type string (expr)))) 

हम अपने स्वयं के डायग्नोस्टिक्स बनाते हैं और चलाते हैं!

आइए विश्लेषक के लिए हमारे नए निदान को लागू करने का प्रयास करें।

ऐसा करने के लिए, आपको स्थापित NoVerify की आवश्यकता है। बाइनरी रिलीज़ को लें यदि आपके पास सिस्टम में गो-टूलचैन नहीं है (यदि आपके पास एक है, तो आप स्रोत से सब कुछ संकलित कर सकते हैं)।

समस्या का बयान

PHP के कई दिलचस्प कार्य हैं, उनमें से एक है parse_str । उसके हस्ताक्षर:

 //   encoded_string,     //   URL,      //   (  ,    result). parse_str ( string $encoded_string [, array &$result ] ) : void 

यदि आप इस उदाहरण को दस्तावेज से देखेंगे तो आप समझेंगे कि यहाँ क्या गलत है:

 $str = "first=value&arr[]=foo+bar&arr[]=baz"; parse_str($str); echo $first; // value echo $arr[0]; // foo bar echo $arr[1]; // baz 

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

अपना खुद का डायग्नोस्टिक्स बनाएं

myrules.php फ़ाइल बनाएँ:

 <?php /** @warning parse_str without second argument */ parse_str($_); 

सामान्य रूप से नियम फ़ाइल शीर्ष स्तर पर अभिव्यक्तियों की एक सूची है, जिनमें से प्रत्येक को एक phpgrep टेम्पलेट के रूप में व्याख्या की गई है। इस तरह के प्रत्येक टेम्पलेट के लिए एक विशेष phpdoc टिप्पणी अपेक्षित है। केवल एक विशेषता की आवश्यकता है - एक चेतावनी पाठ के साथ एक त्रुटि श्रेणी।

अब कुल चार स्तर हैं: error , warning , info और maybe । पहले दो महत्वपूर्ण हैं: यदि कोई कम से कम एक महत्वपूर्ण नियम काम करता है, तो लिंटर निष्पादन के बाद एक गैर-शून्य कोड लौटाएगा। विशेषता के बाद एक चेतावनी पाठ होता है जिसे टेम्पलेट के ट्रिगर होने की स्थिति में लाइनर द्वारा जारी किया जाएगा।

हमारे द्वारा लिखा गया टेम्पलेट $_ का उपयोग करता है - यह एक अनाम टेम्पलेट वैरिएबल है। हम इसे उदाहरण के लिए, $x कह सकते हैं, लेकिन चूंकि हम इस चर के साथ कुछ भी नहीं कर रहे हैं, इसलिए हम इसे "खाली" नाम दे सकते हैं। टेम्पलेट चर और PHP चर के बीच का अंतर यह है कि पूर्व बिल्कुल किसी भी अभिव्यक्ति के साथ मेल खाता है, न कि केवल "शाब्दिक" चर के साथ। यह सुविधाजनक है: हमें अक्सर विशिष्ट चरों की बजाय अज्ञात अभिव्यक्तियों की तलाश करने की आवश्यकता होती है।

एक नया निदान शुरू करना

डीबगिंग के लिए एक छोटी परीक्षण फ़ाइल बनाएँ, test.php :

 <?php function f($x) { parse_str($x); //      } 

इसके बाद, इस फ़ाइल पर हमारे नियमों के साथ NoVerify चलाएं:

 $ noverify -rules myrules.php test.php 

हमारी चेतावनी कुछ इस तरह दिखाई देगी:

 WARNING myrules.php:4: parse_str without second argument at test.php:4 parse_str($x); ^^^^^^^^^^^^^ 

डिफ़ॉल्ट चेक का नाम नियम फ़ाइल और इस चेक को परिभाषित करने वाली लाइन का नाम है। हमारे मामले में, यह myrules.php:4 ।

आप अपना नाम @name <name> विशेषता का उपयोग करके सेट कर सकते हैं।

 /** * @name parseStrResult * @warning parse_str without second argument */ parse_str($_); 

 WARNING parseStrResult: parse_str without second argument at test.php:4 parse_str($x); ^^^^^^^^^^^^^ 

प्रकार के साथ काम करें

पिछला उदाहरण हैलो दुनिया के लिए अच्छा है - लेकिन अक्सर हमें नैदानिक ​​कार्यों की संख्या को कम करने के लिए अभिव्यक्ति के प्रकारों को जानना होगा

उदाहरण के लिए, in_array फ़ंक्शन के लिए , हम तर्क के लिए $strict=true पूछते हैं जब पहला तर्क ( $needle ) स्ट्रिंग प्रकार का होता है।

इसके लिए हमारे पास परिणाम फ़िल्टर हैं।

ऐसा ही एक फिल्टर है @type <type> <var> । यह आपको उन सभी चीजों को त्यागने की अनुमति देता है जो प्रगणित प्रकारों में फिट नहीं होती हैं।

 /** * @warning 3rd arg of in_array must be true when comparing strings * @type string $needle */ in_array($needle, $_); 

यहाँ हमने in_array कॉल के लिए पहले तर्क का नाम दिया है कि इसे एक प्रकार के फ़िल्टर को in_array । एक चेतावनी केवल तभी जारी की जाएगी जब $needle का प्रकार string ।

फ़िल्टर सेट @or ऑपरेटर के साथ जोड़ा जा सकता है:

 /** *     -. * * @warning strings must be compared using '===' operator * @type string $x * @or * @type string $y */ $x == $y; 

ऊपर दिए गए उदाहरण में, पैटर्न केवल उन == अभिव्यक्तियों से मेल खाएगा, जहां कोई भी ऑपरेंड टाइप string । यह माना जा सकता है कि @or बिना सभी फ़िल्टर @and के माध्यम से संयुक्त हैं, लेकिन यह स्पष्ट रूप से इंगित नहीं किया जाना चाहिए।

निदान के दायरे को सीमित करें

प्रत्येक परीक्षण के लिए, आप @scope <name> निर्दिष्ट कर सकते हैं:

• @scope all - डिफ़ॉल्ट मान, सत्यापन हर जगह काम करता है;
• @scope root - केवल शीर्ष स्तर पर लॉन्च;
• @scope local - केवल कार्यों और विधियों के अंदर चलाएं।

मान लीजिए हम फ़ंक्शन बॉडी के बाहर return रिपोर्ट करना चाहते हैं। PHP में, यह कभी-कभी समझ में आता है - उदाहरण के लिए, जब कोई फ़ाइल किसी फ़ंक्शन से जुड़ी होती है ... लेकिन इस लेख में हम इसकी निंदा करते हैं।

 /** * @warning don't use return outside of functions * @scope root */ return $_; 

आइए देखें कि यह नियम कैसे व्यवहार करेगा:

 <?php function f() { return "OK"; } return "NOT OK"; // Gives a warning class C { public function m() { return "ALSO OK"; } } 

इसी तरह, आप require बजाय *_once का उपयोग करने का अनुरोध कर सकते हैं और include :

 /** * @maybe prefer require_once over require * @scope root */ require $_; /** * @maybe prefer include_once over include * @scope root */ include $_; 

अब जब मिलान पैटर्न, कोष्ठक को लगातार ध्यान में नहीं लिया जाता है। पैटर्न (($x)) "सभी अभिव्यक्तियों को डबल ब्रैकेट्स" में नहीं मिलेगा, लेकिन बस किसी भी भाव को कोष्ठक की अनदेखी करते हुए। हालांकि, $x+$y*$z और ($x+$y)*$z जैसा वे चाहते हैं वैसा ही व्यवहार करते हैं। यह सुविधा टोकन ( और ) साथ काम करने की कठिनाइयों से आती है, लेकिन एक मौका है कि आदेश अगले रिलीज में से एक में बहाल किया जाएगा।

ग्रुपिंग टेम्प्लेट

जब टेम्पलेट्स पर phpdoc टिप्पणियों का दोहराव दिखाई देता है, तो टेम्पलेट्स को संयोजित करने की क्षमता बचाव में आती है।

प्रदर्शित करने के लिए एक सरल उदाहरण:

 / ** @ मयबी बाहर निकलने या मरने का प्रयोग न करें * /
 मर ($ _);

 / ** @ मयबी बाहर निकलने या मरने का प्रयोग न करें * /
 बाहर निकलें ($ _);

 / ** @ मयबी बाहर निकलने या मरने का प्रयोग न करें * /
 {
   मर ($ _);
   बाहर निकलें ($ _);
 }

अब कल्पना करें कि इस सुविधा के बिना निम्नलिखित उदाहरण में एक नियम का वर्णन करना कितना अप्रिय होगा!

 /** * @warning don't compare arrays with numeric types * @type array $x * @type int|float $y * @or * @type int|float $x * @type array $y */ { $x > $y; $x < $y; $x >= $y; $x <= $y; $x == $y; } 

लेख में निर्दिष्ट रिकॉर्डिंग प्रारूप प्रस्तावित विकल्पों में से एक है। यदि आप पसंद में भाग लेना चाहते हैं, तो आपके पास ऐसा अवसर है: आपको उन ऑफ़र को +1 करना होगा जो आपको दूसरों से अधिक पसंद हैं। अधिक जानकारी के लिए, यहां क्लिक करें ।

कैसे गतिशील नियम एकीकृत हैं

लॉन्च के समय, NoVerify नियम फ़ाइल को खोजने की कोशिश करता है जो rules तर्क में निर्दिष्ट है।

अगला, इस फ़ाइल को एक नियमित PHP स्क्रिप्ट के रूप में पार्स किया जाता है, और परिणामस्वरूप एएसटी से , उनके लिए बाध्य phpgrep टेम्पलेट्स के साथ नियम वस्तुओं का एक सेट एकत्र किया जाता है।

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

सफलता को phpgrep टेम्प्लेट का मिलान और फ़िल्टर सेट के कम से कम एक के पारित होने के रूप में माना जाता है (वे @or अलग हो जाते हैं)।

इस स्तर पर, नियम तंत्र लाइनर के संचालन को काफी धीमा नहीं करता है, भले ही बहुत सारे गतिशील नियम हों।

मैचिंग एलगोरिदम

भोली दृष्टिकोण के साथ, प्रत्येक एएसटी नोड के लिए, हमें सभी गतिशील नियमों को लागू करने की आवश्यकता है। यह एक बहुत ही अयोग्य कार्यान्वयन है, क्योंकि अधिकांश कार्य व्यर्थ हो जाएंगे: कई टेम्पलेट्स में एक विशिष्ट उपसर्ग होता है जिसके द्वारा हम नियमों को क्लस्टर कर सकते हैं।

यह समानांतर मिलान के विचार के समान है , लेकिन ईमानदारी से एनएफए के निर्माण के बजाय, हम केवल गणनाओं के पहले चरण को "समानांतर" करते हैं।

तीन नियमों के साथ एक उदाहरण के साथ इस पर विचार करें:

 /** @warning duplicated then/else parts of ternary */ $_ ? $x : $x; /** @warning don't call explode with delim="" */ explode("", ${"*"}); /** @maybe suspicious empty body of the if statement */ if ($_); 

यदि हमारे पास एन तत्व और एम नियम हैं, तो एक भोले दृष्टिकोण के साथ हमारे पास प्रदर्शन करने के लिए एन * एम ऑपरेशन हैं। सिद्धांत रूप में, इस जटिलता को रैखिक तक कम किया जा सकता है और O(N) प्राप्त कर सकते हैं - यदि आप सभी टेम्प्लेट को एक में जोड़ते हैं और मैच करते हैं जैसा कि करता है, उदाहरण के लिए, गो से regexp पैकेज।

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

यदि हमारे पास हजारों नियम हैं और हम एक महत्वपूर्ण मंदी महसूस करेंगे, तो एल्गोरिथ्म को अंतिम रूप दिया जाएगा। इस बीच, समाधान की सादगी और परिणामस्वरूप त्वरण मुझे सूट करता है।

पसंद की पीड़ा, या @type बारे में थोड़ा

वर्तमान सिंटैक्स @var और @var डुप्लिकेट @var , लेकिन हमें नए ऑपरेटरों की आवश्यकता हो सकती है, उदाहरण के लिए, "प्रकार समान नहीं है।" कल्पना कीजिए कि यह कैसा लग सकता है।

हमारे पास कम से कम दो महत्वपूर्ण प्राथमिकताएँ हैं:

1. एनोटेशन का पठनीय और संक्षिप्त सिंटैक्स।
2. अतिरिक्त प्रयास के बिना आईडीई से उच्चतम संभव समर्थन।

PhpStorm के लिए एक php-annotations plugin है, जो ऑटो-पूर्णता, एनोटेशन कक्षाओं में संक्रमण और phpdoc टिप्पणियों के साथ काम करने के लिए अन्य उपयोगिता जोड़ता है।

व्यवहार में प्राथमिकता (2) का अर्थ है कि आप ऐसे निर्णय लेते हैं जो आईडीई और प्लगइन्स की अपेक्षाओं के विपरीत नहीं हैं। उदाहरण के लिए, आप एक प्रारूप में एनोटेशन कर सकते हैं जिसे php-annotations प्लगइन पहचान सकता है:

 /** * Type is a filter that checks that $value * satisfies the given type constraints. * * @Annotation */ class Filter { /** Variable name that is being filtered */ public $value; /** Check that value type is equal to $type */ public $type; /** Check that value text is equal to $text */ public $text; } 

फिर प्रकारों के लिए एक फ़िल्टर लागू करना कुछ इस तरह दिखाई देगा:

 @Type($needle, eq=string) @Type($x, not_eq=Foo) 

उपयोगकर्ता Filter की परिभाषा पर जा सकते हैं, उन्हें संभावित मापदंडों (प्रकार / पाठ / आदि) की सूची के साथ संकेत दिया जाएगा।

वैकल्पिक रिकॉर्डिंग के तरीके, जिनमें से कुछ सहकर्मियों द्वारा सुझाए गए थे:

 @type string $needle @type !Foo $x @type $needle == string @type $x != Foo @type(==) string $needle @type(!=) Foo $x @type($needle) == string @type($x) != Foo @filter type($needle) == string @filter type($x) != Foo 

फिर हम थोड़ा विचलित हुए और भूल गए कि यह सब phpdoc के अंदर था, और यह दिखाई दिया:

 (eq string (typeof $needle)) (neq Foo (typeof $x)) 

हालांकि मस्ती के लिए पोस्टफिक्स रिकॉर्डिंग के साथ विकल्प भी आवाज किया गया था। प्रकार और मूल्य बाधाओं का वर्णन करने के लिए एक भाषा को छठी कहा जा सकता है:

 @eval string $needle typeof = @eval Foo $x typeof <> 

सबसे अच्छा विकल्प की खोज अभी भी समाप्त नहीं हुई है ...

फैन के साथ एक्स्टेंसिबिलिटी की तुलना

फ़ान के फायदों में से एक के रूप में, लेख " पीएचपीएसन, फान और भजन के उदाहरण का उपयोग करके पीएचपी कोड का स्थैतिक विश्लेषण " संवेदनशीलता का संकेत देता है।

यहाँ नमूना प्लगइन में क्या लागू किया गया था:

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

इस तरह से प्लगइन कोड दिखता है (स्वरूपण चौड़ाई के लिए अनुकूलित है):

 <?php use Phan\AST\ContextNode; use Phan\CodeBase; use Phan\Language\Context; use Phan\Language\Element\Func; use Phan\PluginV2; use Phan\PluginV2\AnalyzeFunctionCallCapability; use ast\Node; class DefineThirdParamTrue extends PluginV2 implements AnalyzeFunctionCallCapability { public function getAnalyzeFunctionCallClosures(CodeBase $code_base) { $def = function(CodeBase $cb, Context $ctx, Func $fn, $args) { if (count($args) < 3) { return; } $this->emitIssue( $cb, $ctx, 'PhanDefineCaseInsensitiv', 'define with 3 arguments', [] ); }; return ['define' => $def]; } } return new DefineThirdParamTrue(); 

और यहां बताया गया है कि यह NoVerify में कैसे किया जा सकता है:

 <?php /** @warning define with 3 arguments */ define($_, $_, $_); 

हम लगभग एक ही परिणाम प्राप्त करना चाहते थे - ताकि तुच्छ चीजों को यथासंभव सरल बनाया जा सके।

निष्कर्ष

• अपने प्रोजेक्ट में NoVerify का प्रयास करें।
• यदि आपके पास सुधार या बग रिपोर्ट के लिए कोई विचार है, तो हमें इसके बारे में बताएं ।
• यदि आप विकास में भाग लेना चाहते हैं, तो आपका स्वागत है !

लिंक, उपयोगी सामग्री

यहां महत्वपूर्ण लिंक एकत्र किए गए हैं, जिनमें से कुछ पहले से ही लेख में उल्लिखित हैं, लेकिन स्पष्टता और सुविधा के लिए, मैंने उन्हें एक जगह एकत्र किया।

• Habré पर NoVerify के बारे में लेख
• Habré पर phpgrep के बारे में लेख
• आईटी नाइट्स के साथ Phpgrep टॉक वीडियो
• gogrep - सिंटैक्स पैटर्न द्वारा कोड खोज
• ESLint एएसटी चयनकर्ता सिंटेक्स टेम्प्लेट के समान अवधारणा

यदि आपको नियमों के अधिक उदाहरणों की आवश्यकता है, जिन्हें लागू किया जा सकता है, तो आप NoVerify परीक्षणों पर एक नज़र डाल सकते हैं।