CLion 2020.2: دعم نموذج تصميم Makefile والمزيد من C ++ 20 والمزيد

مرحبا هبر!



قضى فريقنا صيفًا مزدحمًا للغاية ، ونحن في عجلة من أمرنا لمشاركتنا نتائجه اليوم. لذا ، نرحب بالإصدار الجديد من CLion 2020.2!







باختصار حول ما تم تضمينه في الإصدار الجديد :

• دعم نموذج تصميم Makefile.
• آخر التحديثات في CMake.
• C++20: explicit(bool), (designated initializers), for .
• : (dangling pointers), , , , .
• -: doctest, Catch2 Google Test. .
• PlatformIO .
• .
• .
• .

Makefile

بعد أن احتفلنا بالذكرى السنوية الخامسة لـ CLion هذا الربيع ، شاركنا على الفور في الإكمال النشط لأكثر الميزات المتوقعة في IDE - دعم المشاريع القائمة على Makefile. قبل ذلك ، لم يكن لدينا سوى نموذج أولي بسيط ، أعطيناه مستخدمينا الأكثر جرأة للمحاولة على انفراد. بفضلهم ، تمكنا من اختبار النموذج الأولي على مجموعة واسعة من مشاريع Makefile ، وإصلاح العديد من المشكلات فيه وفهم القيود الحالية (التي نأمل أن تكون مؤقتة) لحلنا. هدفنا هو السماح للمستخدمين بالعمل مع مشروع Makefile في CLion مع جميع ميزات IDE الذكية مثل التنقل وإعادة البناء وتحليل الكود الثابت وغيرها.



يبدو النهج الحالي باختصار كما يلي: يقوم CLion بتشغيل أمر makeفي مشروعك بخيار إضافي--just-printلتوفير الوقت على التجميع الفعلي. إذا تمكن CLion من تحليل إخراج الأمر بنجاح ، فسيتم فتح المشروع وسيعمل كل شيء!



دعنا نحجز على الفور أن العمل على دعم Makefile في CLion لا يزال بعيدًا عن الاكتمال - لا يزال هناك العديد من القيود والعيوب المعروفة. أبرزها:

• لا يتم دعم المشروعات التي تستخدم libtool ( CPP-19549 ) و distcc و ccache ( CPP-19305 ) والأغلفة الأخرى التي "تخفي" علامات التجميع من الإخراج أو تتداخل مع إخراج الأمر make.
• لم يكن CLion قادرًا بعد على التعامل مع مخرجات غير GNU Makes (مثل NMake و BSD) ( CPP-18723 ).
• لا يدعم المشاريع التي تعطل قائمة أسماء الدلائل أثناء عملية الإنشاء ، لذلك لا يمكن لـ CLion تحديد الملفات التي يشير إليها كل أمر بناء.

ولكن حتى الحل الحالي يسمح لك بالفعل بفتح رمز خادم قاعدة بيانات Linux kernel أو PostgreSQL في CLion. إذا كنت مهتمًا ، فيمكن العثور على القائمة الحالية للمشاريع التي يعمل عليها نموذجنا الأولي (بالإضافة إلى بعض المشاريع التي لا يعمل فيها ، مع المشكلات المشار إليها) في هذه الصفحة .



من السهل جدًا تجربة مشروعك:

1. قم بإعداد مشروع من أجل الحصول على Makefile له (على سبيل المثال ، في كثير من الحالات تحتاج إلى البدء فيه ./configure، لأن CLion نفسها لا تعرف كيفية القيام بذلك حتى الآن).
2. افتح مشروعًا باستخدام ملف | افتح وحدد الدليل الذي يحتوي على المشروع الرئيسي Makefile أو مباشرة هذا الملف نفسه. أكد أنك تريد فتحه كمشروع.
3. CLion , Clean. , make , .
4. , , ! Build.

قد يحتوي الإخراج على بعض التحذيرات ، ولكن إذا اكتمل التنزيل بنجاح بشكل عام (يجب أن تكون هناك علامة خضراء بجوار المهمة الأولى) ، فيمكنك حينئذٍ العمل مع المشروع في CLion.



يمكن العثور على إعدادات وسيطة أمر التمهيد وسلسلة الأدوات المستخدمة للتمهيد وخيارات أخرى في الإعدادات / التفضيلات | البناء والتنفيذ والنشر | Makefile:







لتشغيل تطبيقات Makefile وتصحيحها ، ستحتاج إلى إنشاء تكوينات تطبيق Makefile إضافية. في هذه الحالة ، يمكن تحديد الهدف من القائمة المنسدلة - سيخبرك CLion بالخيارات الموجودة:







في مدونتنا باللغة الإنجليزية ، يمكنك العثور على مزيد من المعلومات حول العمل مع مشاريع Makefile في CLion. نوصي أيضًا بمشاهدة عرض توضيحي قصير (باللغة الإنجليزية):

آخر التحديثات في CMake

كما تظهر الإحصائيات ، فإن نماذج التصميم الثلاثة الأكثر شيوعًا الآن بين مطوري C ++ هي CMake و msbuild و Makefile. وهي CMake التي تقود هذا التصنيف لمدة ثلاث سنوات وتستمر في النمو. لذلك ، نقوم باستمرار بتحديث إصدار CMake المحظور في CLion ونعمل على دعم أحدث الابتكارات في CMake نفسها. هذه المرة قمنا بتحديث الإصدار إلى 3.17 وبناءً عليه قمنا بإضافة دعم لميزتين جديدتين مفيدتين في CMake:

• Ninja Multi-Config ( Debug Release) Ninja ( -G "Ninja Multi-Config"). CLion , CMake . UI, .
• CMake تستحق العناوين المترجمة مسبقًا مزيدًا من الاهتمام. بشكل عام ، فكرة ملفات الرؤوس المترجمة مسبقًا (PCH) ليست جديدة وقد تم دعمها من قبل المترجمين لفترة طويلة. لقد كان CLion أيضًا موجودًا مع PCH لبعض الوقت. الآن ليس عليك أن تتذكر علامات المترجم لـ PCH وتمريرها إلى CMake إلى كل مترجم معين بطريقتك الخاصة ، ولكن ببساطة أضف ملفات رأس إلى متغيرات الهدف PCH عبر الأمر target_precompile_headers. CLion 2020.2 قادر الآن على العمل مع هذا:
  
  
  
  

وتجدر الإشارة أيضًا إلى القدرة على فتح مشروع CMake في CLion من الدليل نتيجة إنشاء CMake ، الآن ليس فقط لمولد Makefile ، ولكن لأي شيء آخر! وفر الوقت - افتح المشاريع التي تم إنشاؤها بالفعل في CLion دون إعادة تشغيل أمر CMake في المشروع.

سي ++ 20

هل تعلم أنه وفقًا لبياناتنا ، هذا العام بالفعل 12٪ من مطوري C ++ يستخدمون معيار C ++ 20 ؟! لذلك ، نحن بالطبع نعمل بنشاط لدعم الميزات الجديدة في CLion. لكن دعنا نتذكر أولاً ما لدينا مع محركات اللغة في CLion.



لذلك ، يوجد في الوقت الحالي اثنان منهم - واحد مدمج يعتمد على Java / Kotlin وآخر جديد إلى حد ما يعتمد على Clangd ، على التوالي ، في C ++ (نستخدم CLion لتطويره). يتم الآن وضع كل الجهود في محرك قائم على Clangd. يبدو أنه احتمال جيد ، على الرغم من أنه لا يمكن تنفيذ الإجراءات على المشروع بأكمله (مثل إعادة البناء) حتى الآن - هنا حتى محرك Java غير كامل وأحيانًا بطيء يفوز بسبب أي تحسينات محددة وقرارات مؤجلة ، وبالطبع بسبب وجود ذاكرة تخزين مؤقت الرموز اللازمة لإعادة البناء.



لكن Clangd لديها ميزة إضافية كبيرة جدًا - يعمل المجتمع بأكمله هناك لدعم أحدث معايير C ++ في Clang ، لأن المشروع مفتوح. هذا ، بالطبع ، لا يعني أننا لسنا بحاجة إلى فعل أي شيء على الإطلاق - لا يزال هذا الدعم بحاجة إلى التكيف مع احتياجات CLion على أي حال. لكن هذا بالفعل أسهل من كتابة دعم لميزات C ++ من البداية! وعلى أساس الدعم في Clang ، يمكنك كتابة تحليلك الخاص أو القيام ببعض الميزات الخاصة (على سبيل المثال ، قمنا بإكمال تلقائي للمفاهيم منذ عدة إصدارات).



لقد تأكدنا من أن التحديث الأخير لمحرك Clangd ، الذي جاء مع LLVM ، يتصرف بشكل أكثر ثباتًا في كود C ++ 20 ، وبشكل عام ، وفقًا لإحصائياتنا المدمجة ، أصبح محرك Clangd أكثر استقرارًا. لذلك ، تمت إزالة القدرة على تعطيل محرك Clangd تمامًا من الإعدادات. لكنها أضيفت إلى الإعدادات / التفضيلات | اللغات والأطر | C / C ++ | معلومات Clangd حول المراجعة التي تم بناء محركنا بها. الآن أنت تعرف ما يمكن توقعه منه فيما يتعلق بدعم C ++ وتحليل Clang-Tidy المدمج:







بالمناسبة ، تحتوي مساعدتنا عبر الإنترنت على مقالة ممتازة مع تحليل مقارن للمحركين من حيث دعم قدرات C ++.



والآن حول ما تمت إضافته بالفعل من دعم C ++ 20:

• إنجاز قانون للC ++ 20 كلمة رئيسية: char8_t، constevalو constinit، co_await، co_return، و co_yield.
• استكمال الحقول من الفئة الأساسية في المُهيئ المعين:
  
  
  
  
• تم explicit(bool)الآن تمييز البنية بشكل صحيح ، وتعمل فيه تلميحات الاسم والتنقل وإعادة البناء:
  
  
  
  
• بالنسبة للحلقات forالمستندة إلى النطاق مع المُهيِّئات ، نجحت إعادة تسمية متغيرات الحلقة.

محلل كود ثابت

في الإصدار الأخير ، قمنا بنقل أكثر تحليلاتنا "ثقلاً" - تحليل تدفق البيانات - إلى محرك مستند إلى Clangd. هذا بشكل أساسي لتحسين الأداء. ولكن ، كما يحدث غالبًا ، أثناء إعادة البناء ، تم العثور على العديد من المشاكل وعدم الدقة. لذلك في الإصدار 2020.2 ، واصلنا تحسين هذا التحليل وإصلاح الأخطاء فيه:

• , , .
• DFA Simplify code Loop condition is never updated. , :
  
  
  
  
  
  
  
  , :
  
  
  
  
  
  
  
  - , . , Clang-Tidy (clang-tidy:bugprone-infinite-loop), - . CLion :
  
  
  
  
• CLion (dangling pointers)! (, ), :
  
  
  
  
• , Concepts C++20, - auto, :
  
  
  
  

في هذا الإصدار ، تحولت Inspection Hector المفضل لدى الجميع (الذي حاول بعض مستخدمينا السخرية منه دون جدوى ) إلى أداة فحص جديدة تقع في الزاوية اليمنى العليا من منطقة المحرر. الآن هناك خيارات لتعيين مستوى الإضاءة الخلفية (من إظهار جميع المشكلات إلى تعطيل محلل الكود تمامًا) ، وعند النقر ، تفتح نافذة لنتائج التحليل الثابت لهذا الملف:

وحدة التجارب

يُظهر البحث المذكور هنا أكثر من مرة أن 34٪ من مطوري C ++ لا يكتبون أي اختبارات للوحدة . أود أن أصدق أنهم في المقابل يجرون الاختبار بطريقة أخرى. جزء من المشكلة هو أن C ++ ليس لديها نموذج تصميم قياسي أو مدير تبعية قياسي ، مما يعني أن إضافة إطار عمل لاختبار الوحدة إلى مشروعك ليس بالأمر السهل. ولكن الآن أصبحت ما يسمى بإطارات العمل header-only شائعة بشكل خاص ، والتي يسهل توصيلها بمشروعك - أضف ملف رأس واكتب الاختبارات بنفسك. من جانبنا ، نحاول في IDE دعم أكبر عدد ممكن من الخيارات. في هذا الإصدار ، تمت إضافة الدليل إلى المجموعة من Google Test، Catch، Boost.Test. بالمناسبة ، كان لدينا منشور مدونة ضيف منذ فترةمن مؤلفه ، حيث تحدث فيكتور عن مزايا هذا الإطار.



يتضمن دعم CLion الأشياء المعتادة:

• كشف الاختبار التلقائي.
• الإنشاء التلقائي للتكوينات لتشغيل الاختبارات وتصحيح الأخطاء.
• ينتج عن نتائج الاختبار نافذة خاصة مدمجة بها خيارات ترشيح وترتيب مختلفة ، بالإضافة إلى الانتقال إلى كود مصدر الاختبار بنقرة واحدة.
• الرموز الموجودة في المحرر ، في الجزء الأيمن ، لتشغيل الاختبارات وتحديد حالة آخر تشغيل للاختبارات.

تم أيضًا تحديث دعم Google Test و Catch2:

• تمت إضافة دعم اختبارات القوالب لـ Catch2.
• بالنسبة لـ Google Test ، دعم الماكرو GTEST_SKIP()، والذي يمكن أن يكون مفيدًا جدًا إذا كنت تريد أن تكون قادرًا على تخطي بعض الاختبارات ، على سبيل المثال ، في بيئات معينة.

فيديو نظرة عامة صغيرة حول التحسينات في دعم اختبار الوحدة من محامينا (بالمناسبة ، مؤلف إطار Catch / Catch2):





تحذير أسئلتك حول CTest: جعله أكثر صعوبة ، لأن هذا ليس إطار عمل "عادي" ، ولكن مستوى معين من التجريد لتشغيل أي شيء كاختبار. لكننا نخطط لبعض التكامل في وقت مبكر من عام 2020.3!

و

الأكثر إثارة للاهتمام ، ربما ، تمت مناقشته الآن باختصار حول الباقي. كان يجب أن نبدأ بهذا ، لكن CLion 2020.2 يتضمن العديد من التحسينات الصغيرة ولكنها مهمة لأداء المحرر وإصلاحات توقف المحرر. أحد هذه التحسينات ، على سبيل المثال ، هو إدخال شرطة مائلة للخلف عند الضغط عليه Enter داخل تعريف ماكرو . يبدو أن هذا يساعد على إنتاجية المحرر؟ الحقيقة هي أن السطر الجديد على الأرجح هو جزء من تعريف الماكرو الحالي ، وإدراج الشرطة المائلة للخلف يسمح لك بتجنب إعادة التوزيع غير الضرورية لمجموعة من التعليمات البرمجية ، وبالتالي مكابح المحرر.



الى جانب:

• PlatformIO — , platformio.ini CMake .
• , IntelliJ . : GitHub Pull Requests Git WSL2 ( WSL2, CLion Git ).
• فيما يتعلق بأدوات تصحيح الأخطاء في عام 2020.2 ، تمكنا من عمل أقل مما هو مخطط له. في الأساس ، تم تأجيل جميع المهام الكبيرة إلى عام 2020.3 (تصحيح الأخطاء كجذر ، تصحيح أخطاء تفريغ النواة). ولكن في هذا الإصدار قمنا بترقية الإصدار المحظور من GDB إلى 9.2 وقمنا أيضًا بتحديث طابعات GDB STL الجميلة. تم إجراء العديد من التحسينات ، الوظيفية والأداء والاستقرار في مصحح الأخطاء المستند إلى LLDB لسلسلة أدوات Microsoft Visual C ++.

هذا كل شيء لهذا اليوم. هل قرأت حتى النهاية؟ شكرا جزيلا لكم على اهتمامكم! جربها ، اكتب الأسئلة والاقتراحات وعبارات التعجب في التعليقات - يسعدنا دائمًا قراءتها والإجابة عليها!



CLion فريق

الدافع لتطوير