مرحبا يا هبر! بدأ العديد منهم بالفعل الاستعداد لعطلة رأس السنة الجديدة ، لشراء الهدايا ، شخص ما يخطط لرحلة لقضاء عطلة رأس السنة الطويلة. وفي JetBrains ، لا يزال الوقت حارًا بالنسبة لنا لإصدار إصدارات المنتج. أنا في عجلة من أمرك اليوم لأطلعكم على الأخبار المتعلقة بالإصدار الذي تم إصداره مؤخرًا من بيئة التطوير عبر الأنظمة الأساسية لدينا من أجل C و C ++ - CLion 2019.3.
كان الهدف الرئيسي من هذا الإصدار ، على الرغم من أنه مثير للشفقة ، أن الجودة. قررنا التركيز على المشكلات التي كانت تزعج مستخدمينا لفترة طويلة - أولاً وقبل كل شيء ، إنتاجية المحرر واستجابته ، وثانياً ، الأخطاء والتشوهات والميزات الشائعة للغاية ، ولكنها مفقودة.
بادئ ذي بدء ، باختصار حول أهم شيء في هذا الإصدار:
- إدخال تحسينات على سرعة المحرر واستجابته ، ويتم تنفيذ الإكمال التلقائي بشكل أساسي في محركنا استنادًا إلى Clangd.
- مولد النينجا في CMake ، وإعدادات CMake الافتراضية وغيرها من التحسينات طراز التصميم.
- تحديثات في التكامل مع مصحح الأخطاء.
- إجراء جديد للتبديل بين ملفات الرأس والحامض.
- تحليل رمز أكثر دقة: فحص جديد للوظائف الافتراضية ، وكذلك التدقيق الإملائي في CMake وفي تعليقات Doxygen.
- دعم المفاهيم من C ++ 20 القياسية.
- مقاييس تغطية الكود.
- WSL2 ، اصطلاحات التنسيق والتسمية من Microsoft ، تحديثات دعم VCS ، والمزيد.
سنتحدث بمزيد من التفصيل أدناه ، ولكن إذا كنت مستعدًا لتجربته الآن ، فقم بالدخول إلى الموقع وتنزيله من
موقعنا . كالعادة ، تتوفر نسخة تجريبية مجانية لمدة 30 يومًا.
أداء المحرر
استنادًا إلى الإحصائيات التي يوافق العديد من المستخدمين على إرسالها إلينا ، فإن الإجراء الأكثر شيوعًا في CLion هو
الإكمال التلقائي . لقد قررنا التركيز عليه في هذا الإصدار لجعله أكثر استجابة. للقيام بذلك ، أضفنا واحدًا آخر ، استنادًا إلى Clangd ، إلى مزودي الإكمال التلقائي الموجودين بالفعل في IDE. خلاصة القول هي أن جميع الموردين يعملون بالتوازي ، وبمجرد أن تكون النتائج الأولى جاهزة ، تعرض CLion قائمة منسدلة من الخيارات ، مع الاستمرار في تحميل الخيارات الأخرى حسب الحاجة.
بالطبع ، أردنا أن نفهم ما إذا كان هذا النهج الهجين يوفر فوائد. أظهرت القياسات أنه في المشروعات البسيطة ، لا تختلف سرعة بائع CLion والبائع القائم على Clangd كثيرًا. ولكن في المشروعات المعقدة مثل LLVM ، و Qt ، و Boost ، و Eigen ، تظهر النتائج المائة الأولى من Clangd بشكل أسرع. القاضي لنفسك:
اقرأ المزيد عن القياسات في
مقالة منفصلة على مدونة CLion باللغة الإنجليزية.
من بين التحسينات المهمة الأخرى ، تجدر الإشارة إلى تسريع النظام الأساسي لوقت إطلاق IDE. تم تحقيق ذلك من خلال موازاة العديد من العمليات في البداية ، وإعادة تنظيم الفئات المحملة في البداية ، وتحسين تحميل الخط على ماك. تعتمد الأرقام المحددة التي يجب تسريعها على إعدادات البيئة والسيارة والمنصة وعوامل أخرى.
في CLion ، للأسف الشديد ، لا يزال هناك تعليق واجهة المستخدم. نحن نحاول تجميعها وفقًا للمشكلة الأصلية وإصلاح مشكلة واحدة تلو الأخرى. لذلك ، في هذا الإصدار ، قمنا بإصلاح التجميد في حالات "عرض الاستخدامات المفتوحة" ، عند التبديل إلى إعلان ، عند إعادة تسمية التوجيه
#include ، عند استخدام فتات الخبز والحذف الآمن ، وكذلك في الحالات الأخرى. تظل تعليق واجهة المستخدم المشكلة الأكثر إلحاحًا بالنسبة لنا ، لذلك سنواصل هذا العمل بالتأكيد في الإصدارات المستقبلية.
وأخيرا ،
إعادة تسمية تسريع إعادة بناء . لا يمكن لإعادة التسمية هذه إعادة تسمية استخدام الاسم في الكود فحسب ، ولكن أيضًا في السلسلة الحرفية والتعليقات. ولكن هذا ليس ضروريًا دائمًا ، وقد تم البحث عن الاسم قبل أن يشير مستخدم IDE إلى الاستخدامات المحددة التي سيتم إعادة تسميتها. هذا أدى إلى تأخير طويل في العثور على اسم شائع. الآن يمكنك أولاً تحديد عملية بحث فقط عن طريق الرمز ، وبعد ذلك فقط تبدأ عملية البحث نفسها. للقيام بذلك ، انتقل إلى الإعدادات / التفضيلات | محرر | عام | يجب تعطيل Refactorings "تمكين الوضع في مكان". في هذه الحالة ، عندما يتم استدعاء إعادة التوطين (Shift + F6 افتراضيًا على Windows / Linux ، ،F6 على macOS) ، ستفتح CLion على الفور مربع حوار إعادة تسمية ، حيث يمكنك تحديد معلمات البحث:
CMake تصميم نموذج التحسينات
هنا ، يجب أن يكون العديد منكم ينتظر إعلان دعم Makefiles. لكن حتى الآن لا يتوفر سوى نهج
شبه تلقائي لتكاملها من خلال قاعدة بيانات الترجمة. لا يزال هناك المزيد من الدعم المحلي قيد التطوير ، لكن في دورة الإصدار هذه قطعنا خطوات كبيرة ولدينا كل فرصة لإظهار دعم جديد للإصدار التالي 2020.1 ، في نهاية مارس 2020.
لكننا حققنا الفرصة التي طال انتظارها لدعم CMake - القدرة على تحديد أي مولد CMake ، بما في ذلك مولد
Ninja المتوقع من قبل المستخدمين! في السابق ، استخدمنا Makefiles ومولدات مشابهة له ، حيث قمنا
بتوزيع الملفات الناتجة (بشكل أكثر دقة ، كانوا
-G "CodeBlocks - Unix Makefiles" ، وعلى Windows
-G "CodeBlocks - MinGW Makefiles" و
-G "CodeBlocks - NMake Makefiles" ). الآن يمكنك تحديد أي مولد في ملف تعريف CMake في CLion:
هذا ممكن فقط عند استخدام CMake الإصدار 3.15 وما بعده ، حيث يتم تنفيذه من خلال CMake File API ، ويعمل على جميع الأنظمة الأساسية ، عن بعد ، ل WSL / WSL2.
لاحظ أن المولدات مثل Xcode و Visual Studio هي مولدات متعددة ، أي أنها تنشئ ملفات لجميع أنواع التجميعات (Debug ، Release ، وما إلى ذلك) ، ولكن سيستخدم CLion نوع التجميع المحدد فقط في CMake الشخصي.
قدم هذا الإصدار أيضًا
إعدادات CMake الافتراضية . هذا يعني أنه بالنسبة لجميع المشاريع الجديدة في CLion ، يمكنك استخدام نفس الإعدادات المحددة مسبقًا ، مثل مولد CMake أو دليل إنشاء CMake. يمكن تحديد الإعدادات في ملف | إعدادات أخرى | إعدادات للمشاريع الجديدة ...
من بين التحسينات المهمة في نموذج مشروع CMake ، لا يزال من الجدير الإشارة إلى القدرة على إعادة تحميل التكوينات الصالحة ، حتى إذا كانت هناك تغييرات غير صالحة موجودة في المشروع. قد يكون ذلك مفيدًا إذا قمت بتكوين العديد من التكوينات عن بُعد غير المتوفرة حاليًا ، ولكنك ترغب في إعادة تحميل التكوينات المحلية على الأقل.
تحديث تكامل المصحح
في مصحح الأخطاء ، قررنا إصلاح المشكلات وأوجه القصور التي تهم مستخدمينا أكثر. أولاً ، يقرأ CLion الآن
.gdbinit / .lldbinit من دليل المشروع . يعد هذا مفيدًا إذا كنت ترغب في تخصيص بعض إعدادات مصحح الأخطاء أو إضافة طابعات جميلة ، ولكن فقط لمشروع محدد. في السابق ، كان عليك تحديد هذه الإعدادات في ملفات تكوين المصحح في دليل المستخدم. يمكنك الآن تكوين هذه المعلمات الخاصة بالمشروع. ولكن لكي يعمل هذا ، تحتاج إلى تمكين هذا السلوك في مصحح الأخطاء نفسه في الإعدادات على مستوى دليل المستخدم (اقرأ كيفية القيام بذلك لـ
GDB وكيفية
LLDB ).
التكامل مع LLDB متاح على نظامي التشغيل Linux و macOS. في الإصدار الجديد ، قمنا بترقية LLDB المضمّن إلى الإصدار 9.0 ، وفي الوقت نفسه استعرضنا عالميًا جميع الطابعات المدمجة. بفضل هذا ، تم تحسين أداء الحاويات القياسية على كلا النظامين بشكل كبير. يمكن الاطلاع على مقارنات تفصيلية في مدونتنا
باللغة الإنجليزية . تجدر الإشارة إلى أن
مكتبة libc ++ ، على نظام
macOS ، تتعامل بشكل أفضل من
libstdcxx . يبدو أن هذا يتوافق مع شعبية هذه المكتبات على هذا النظام الأساسي ، ولكن إذا كنت تستخدم
libstdcxx على
macOS ، فيرجى إخبارنا بمزيد من المعلومات عن مثل هذه الحالات في التعليقات.
لدى CLion الآن
عدة خيارات للعمل عن بُعد مع مشروع وتصحيح الأخطاء. من الخيار البعيد تمامًا ، عندما يحدث التجميع وتصحيح المشروع على جهاز بعيد ، إلى الخيارات عندما يتم تصحيح المشروع فقط عن بُعد. هذا كل شيء للحالة الثانية ، أضفنا تهيئة أخرى إلى خادم CLD -
Remote GDB . على عكس
GDB Remote Debug القديم (نعم ، لم يكن لدينا أي أسماء ، نحن نوافق على ذلك) ، في التكوين الجديد ، تبني CLion المشروع بنفسها (ربما تحتاج إلى تكوين إعدادات التجميع المتقاطع) ، وتنزيل الملف القابل للتنفيذ على الجهاز البعيد ، و يعمل البرنامج الخاص بك تحت gdbserver المحدد. التكوين القديم الآن أكثر ملاءمة للخيارات المعقدة ، عندما يكون الكود على جهاز واحد ، التجميع على الثاني ، وتصحيح الأخطاء على الثالث. أو إذا كان التجميع غير ممكن.
انتقل إلى ملفات الرأس / المصدر
نعم فعلت! لقد قمنا في النهاية بإضافة إجراء منفصل للتبديل بين ملفات الرأس والحامض. ما هو الفرق الرئيسي من النظام الأساسي القديم
Go to Related Symbol ؟ والحقيقة هي أن
Go to Related Symbol ، كعمل مشترك على النظام الأساسي ، تحاول أن تكون دقيقة للغاية واختر أحد الخيارات الصحيحة. هذا طويل وغير صحيح دائمًا في حالة C ++. تصرف
Go to Header / Source الجديد يتصرف بشكل مختلف:
- إذا لم يكن هناك خيار واحد صحيح خلال 500 مللي ثانية ، فستظهر قائمة منسدلة من الخيارات المناسبة ، والتي يمكن للمستخدم من خلالها تحديد الأنسب.
- إذا كان المستخدم قد انتقل بالفعل من هذا الملف ، فسيكون الملف الذي كان يتنقل إليه في أعلى القائمة.
- علاوة على ذلك ، ستكون الملفات من نفس الدليل بنفس الاسم.
- ثم ستستمر نتائج البحث عن مطابقة التعريفات والتعريفات.
تجدر الإشارة إلى ميزة البحث (حيث أن مستخدمينا قد التقوا بها بالفعل) - يجري البحث الآن على ملفات مضمنة / شاملة. هذا هو الحد الزمني الضروري حتى لا تخلط بين الأحرف التي تحمل الاسم نفسه من أهداف مختلفة.
تحليل الكود
لقد ظهر فحص جديد في محلل الكود في CLion. يمسك المواقف عندما يتم استدعاء الوظائف الافتراضية من المنشئات أو المدمرات. لماذا هذا أمر سيء وقد
نوقشت بالفعل
الكثير . الآن يحذر CLion من مثل هذه الحالات:
المدقق الإملائي هو جزء لا يتجزأ من بيئة التطوير المتكاملة. كلنا نرتكب أخطاء إملائية ، ومن ثم يصعب على زملائنا قراءة الشفرة والتعليقات. لذلك ، من الجيد أن يبرز IDE مثل هذه الأخطاء. في هذا الإصدار ، قمنا بتضمين التدقيق الإملائي في ملفات CMake وتعليقات وثائق تنسيق Doxygen:
أخطاء إملائية أقل - رمز أكثر قابلية للقراءة!
مفاهيم من C ++ 20
يبذل فريقنا جهدًا كبيرًا في محرك اللغات المستندة إلى Clangd. ويقوم مجتمع C ++ العالمي بتطوير Clang بنشاط. في هذا الإصدار ، توحدنا - اتخذنا فرع Clang التجريبي بدعمًا لمفاهيم من C ++ 20 ، التي طورها Saar Raz ، وصبناها في فرع Clangd الخاص بنا. وبالتالي ، حصلنا على إبراز الكود مع المفاهيم والتحققات الأساسية لمحلل Clang في CLion:
لكننا لم نتوقف عند هذا الحد. وفي محركنا المستندة إلى Clangd ، قمنا بتنفيذ بعض الحالات المفيدة للإكمال التلقائي ، والتحقق من استخدام مفهوم ما ، وإعادة
تسمية إعادة بيع المباني للمفاهيم ، وإجراءات التنقل والبحث ،
انتقل إلى التعريف والبحث
عن الاستخدامات .
الإكمال التلقائي لمعلمات النماذج التي تخضع لقيود:
الإكمال التلقائي لـ
std::is_same<Other, T> و
same_as<T, U> :
يمكنك قراءة المزيد عن عملنا المشترك بشأن المفاهيم في
مدونة اللغة الإنجليزية . يوجد أيضًا تسجيل فيديو للتقرير الصادر عن CppCon 2019 ، والذي قدم فيه Saar Raz تطبيق مفهومه في Clang وعملنا المشترك على دعم المفاهيم في CLion.
مقاييس تغطية الكود
تعد تغطية الشفرة فرصة ينتظرها مستخدمو CLion ويطالبون بها. في الإصدار الأخير ، بدأ فريق AppCode العمل في هذا الاتجاه ، وفي هذا اخترنا الأمر لحالات C ++ عبر منصة موجودة بالفعل في CLion.
تعمل مقاييس تغطية كود CLion من خلال التكامل مع أدوات llvm-cov / gcov. في هذه الحالة ، يمكنك تشغيل كل من اختبارات الوحدة والتكوينات العادية ، ووفقًا لتنفيذها ، سيتم حساب عدد مرات تنفيذ بعض التعليمات البرمجية. يمكن تلخيص نتائج العديد من عمليات الإطلاق ، إذا رغبت في ذلك ، بشكل عام.
يمكنك رؤية النتائج مباشرة إما في نافذة تغطية خاصة:
... أو في الفتحة اليسرى في المحرر.
حسنًا ، والأهم من ذلك: لكي ينجح هذا ، يلزمك تمرير خيارات تجميع خاصة:
- لدول مجلس التعاون الخليجي:
-fprofile-arcs -ftest-coverage أو -fprofile-arcs -ftest-coverage . - بالنسبة إلى Clang: إما الأعلام نفسها كما هو الحال مع GCC ، أو
-fprofile-instr-generate -fcoverage-mapping . ستكون الاختلافات في طريقة تجميع مقاييس التغطية فقط.
لماذا لا تتجاوز CLion هذه المعايير؟ في الغالب لأن لدينا قاعدة عدم التدخل في عملية التحويل البرمجي. نعم ، وليس من الواضح دائمًا مكان تمرير هذه المعلمات في حالة عدم CMake. لكننا الآن نفكر في خيارات لكيفية أتمتة مثل هذه الحالات في المستقبل (لدينا مشكلة مماثلة مع المطهرات).
يمكنك قراءة المزيد حول خيارات الترجمة وعن عرض المقاييس في CLion في
المساعدة عبر الإنترنت الخاصة بنا.
تحسينات أخرى
من بين التحسينات الهامة الأخرى في هذا الإصدار:
- دعم للنظام الفرعي WSL2. الإعدادات في CLion هي نفس إعدادات الإصدار الأول من WSL.
- دعم قواعد التنسيق والتسمية من Microsoft. يتوفر هذا النمط على قدم المساواة مع Google و LLVM و Qt و GNU و Stroustrup وغيرها في الإعدادات / التفضيلات | محرر | رمز النمط | C / C ++.
- تحديثات البرنامج المساعد IntelliJ Rust (منشور تفصيلي على مدونة اللغة الإنجليزية مخصص لهذه التغييرات).
- تحديثات دعم VCS وواجهة المستخدم والتغييرات الأخرى من النظام الأساسي IntelliJ.
عرض
في الختام ، شريط فيديو تقليدي عن الميزات الجديدة في CLion 2019.3 (باللغة الإنجليزية):
شكرا لك على القراءة حتى النهاية! بالتأكيد لديك أسئلة ورغبات وتقارير أخطاء وأفكار فقط - نحن في انتظارهم في التعليقات! كما هو الحال دائمًا ، سنكون سعداء بالإجابة ومناقشة أفكارك.
فريق JetBrains CLion الخاص بك
محرك لتطوير