Halo, Habr! Banyak yang sudah mulai mempersiapkan liburan Tahun Baru, untuk membeli hadiah, seseorang merencanakan perjalanan untuk liburan panjang Tahun Baru. Dan di JetBrains, masih waktu yang panas bagi kami untuk merilis rilis produk. Hari ini saya sedang terburu-buru untuk berbagi dengan Anda berita tentang rilis baru-baru ini dirilis lingkungan pengembangan lintas platform kami untuk C dan C ++ - CLion 2019.3.
Tujuan utama dari rilis ini adalah, betapapun menyedihkannya, kualitasnya. Kami memutuskan untuk fokus pada masalah yang telah lama mengganggu pengguna kami - pertama-tama, produktivitas dan responsif dari editor, dan kedua, bug, defisiensi dan fitur yang sangat populer, tetapi hilang.
Untuk mulai dengan, secara singkat tentang hal terpenting dalam rilis ini:
- Peningkatan kecepatan editor dan responsif, terutama pelengkapan otomatis yang diterapkan di engine kami berdasarkan Clangd.
- Generator Ninja di CMake, pengaturan CMake default dan peningkatan model desain lainnya.
- Pembaruan dalam integrasi dengan pengadu.
- Tindakan baru untuk beralih antara file header dan masam.
- Analisis kode yang lebih akurat: pemeriksaan baru untuk fungsi virtual, serta pemeriksaan ejaan dalam CMake dan dalam komentar Doxygen.
- Dukungan untuk konsep dari standar C ++ 20.
- Metrik cakupan kode.
- WSL2, konvensi pemformatan dan penamaan Microsoft, pembaruan dukungan VCS, dan banyak lagi.
Kami akan berbicara lebih detail di bawah ini, tetapi jika Anda siap untuk mencobanya sekarang, maka pergi dan unduh build dari
situs kami . Seperti biasa, percobaan gratis selama 30 hari tersedia.
Kinerja editor
Dilihat oleh statistik yang disetujui oleh banyak pengguna untuk dikirimkan kepada kami, tindakan yang paling umum digunakan di CLion adalah pelengkapan
otomatis . Kepada dia kami memutuskan untuk fokus dalam rilis ini untuk membuatnya lebih responsif. Untuk melakukan ini, kami menambahkan satu lagi, berdasarkan Clangd, ke penyedia autocomplete yang sudah ada di IDE. Intinya adalah bahwa semua pemasok bekerja secara paralel, dan segera setelah hasil pertama siap, CLion menampilkan daftar turun bawah opsi, terus memuat opsi lain sesuai kebutuhan.
Tentu saja, kami ingin memahami apakah pendekatan hibrid semacam itu memberikan manfaat. Pengukuran menunjukkan bahwa pada proyek-proyek sederhana kecepatan vendor CLion dan vendor berbasis Clangd tidak jauh berbeda. Tetapi pada proyek-proyek kompleks seperti LLVM, Qt, Boost, Eigen, seratus hasil pertama dari Clangd tampak jauh lebih cepat. Nilailah sendiri:
Baca lebih lanjut tentang pengukuran dalam
artikel terpisah di blog CLion berbahasa Inggris.
Di antara peningkatan signifikan lainnya, perlu dicatat percepatan platform waktu peluncuran IDE. Itu dicapai dengan memparalelkan banyak proses di awal, mengatur ulang kelas yang dimuat di awal, dan mengoptimalkan pemuatan font pada macOS. Angka-angka spesifik untuk mempercepat tergantung pada pengaturan lingkungan, mobil, platform dan faktor lainnya.
Di CLion, kami sangat menyesal, masih ada antarmuka pengguna yang hang. Kami mencoba mengelompokkannya sesuai dengan masalah awal dan memperbaiki satu demi satu masalah. Jadi, dalam rilis ini kami memperbaiki pembekuan dalam kasus Tampilan Penggunaan yang terbuka, saat beralih ke deklarasi, saat mengganti nama direktif
#include , saat menggunakan remah roti dan penghapusan yang aman, serta dalam kasus lain. Penangguhan antarmuka pengguna tetap menjadi masalah paling mendesak bagi kami, jadi kami pasti akan melanjutkan pekerjaan ini di rilis mendatang.
Dan akhirnya,
Ganti nama akselerasi refactoring . Refactoring ini tidak hanya dapat mengubah nama penggunaan nama dalam kode, tetapi juga dalam string literal dan komentar. Tapi ini tidak selalu diperlukan, dan pencarian nama dilakukan sebelum pengguna IDE menunjukkan penggunaan tertentu yang akan diubah namanya. Hal ini menyebabkan penundaan lama dalam menemukan nama populer. Sekarang Anda pertama-tama dapat memilih pencarian hanya dengan kode, dan hanya kemudian memulai pencarian itu sendiri. Untuk melakukan ini, buka Pengaturan / Preferensi | Editor | Umum | Refactorings harus dinonaktifkan "Aktifkan mode di tempat". Dalam hal ini, ketika refactoring disebut (Shift + F6 secara default di Windows / Linux, ⇧F6 di macOS), CLion akan segera membuka dialog Rename, di mana Anda dapat menentukan parameter pencarian:
Perbaikan Model Desain CMake
Di sini, banyak dari Anda pasti telah menunggu pengumuman dukungan untuk Makefiles. Namun sejauh ini hanya pendekatan
semi-otomatis untuk integrasi mereka melalui database kompilasi yang tersedia. Lebih banyak dukungan asli masih dalam pengembangan, tetapi dalam siklus rilis ini kami telah membuat langkah besar dan kami memiliki setiap kesempatan untuk menunjukkan dukungan baru untuk rilis berikutnya 2020.1, sekitar akhir Maret 2020.
Tapi kami membuat peluang yang paling lama ditunggu untuk mendukung CMake - kemampuan untuk menentukan generator CMake, termasuk generator
Ninja yang sangat diharapkan oleh pengguna! Sebelumnya, kami menggunakan Makefile dan generator yang mirip dengan itu, karena kami mengurai file yang dihasilkan (lebih tepatnya, mereka adalah
-G "CodeBlocks - Unix Makefiles" , dan pada Windows
-G "CodeBlocks - MinGW Makefiles" dan
-G "CodeBlocks - NMake Makefiles" ) Sekarang Anda dapat menentukan generator apa saja di profil CMake di CLion:
Ini hanya mungkin bila menggunakan CMake versi 3.15 dan lebih tinggi, karena diterapkan melalui API File CMake, dan bekerja pada semua platform, dari jarak jauh, untuk WSL / WSL2.
Saya perhatikan bahwa generator seperti Xcode dan Visual Studio adalah multi-generator, yaitu, mereka menghasilkan file untuk semua jenis rakitan (Debug, Rilis, dll.), Tetapi CLion hanya akan menggunakan jenis rakitan yang ditentukan dalam Profil CMake.
Rilis ini juga memperkenalkan
pengaturan CMake default . Ini berarti bahwa untuk semua proyek baru di CLion, Anda dapat menggunakan pengaturan yang telah ditentukan sebelumnya, seperti generator CMake atau direktori untuk menghasilkan CMake. Pengaturan dapat ditentukan dalam File | Pengaturan Lainnya | Pengaturan untuk Proyek Baru ...
Dari peningkatan penting pada model proyek CMake, masih layak menunjukkan kemampuan untuk memuat ulang konfigurasi yang valid, bahkan jika yang tidak valid lainnya hadir dalam proyek. Ini dapat berguna jika Anda telah mengkonfigurasi beberapa konfigurasi jarak jauh yang saat ini tidak tersedia, tetapi ingin memuat ulang setidaknya konfigurasi lokal.
Pembaruan Integrasi Debugger
Dalam debuggers, kami memutuskan untuk memperbaiki masalah dan kekurangan yang paling mengkhawatirkan pengguna kami. Pertama, CLion sekarang membaca
.gdbinit / .lldbinit dari direktori proyek . Ini berguna jika Anda ingin menyesuaikan beberapa pengaturan debugger atau menambahkan printer cantik, tetapi hanya untuk proyek tertentu. Sebelumnya, Anda harus menentukan pengaturan ini di file konfigurasi debugger di direktori pengguna. Sekarang Anda dapat mengkonfigurasi parameter ini khusus untuk proyek. Tetapi agar ini berfungsi, Anda harus mengaktifkan perilaku ini di debugger itu sendiri dalam pengaturan di tingkat direktori pengguna (baca bagaimana melakukan ini untuk
GDB dan bagaimana ke
LLDB ).
Integrasi dengan LLDB tersedia di Linux dan macOS. Dalam rilis baru, kami meningkatkan LLDB bawaan ke versi 9.0, dan pada saat yang sama secara global meninjau semua printer cantik bawaan. Berkat ini, kinerja kontainer standar di kedua platform telah meningkat secara signifikan. Perbandingan komparatif dapat ditemukan di
blog berbahasa Inggris kami. Perlu dicatat bahwa pada platform macOS,
libc ++ library menangani jauh lebih baik daripada
libstdcxx . Ini tampaknya sesuai dengan popularitas perpustakaan ini pada platform ini, tetapi jika Anda menggunakan
libstdcxx di macOS, silakan beri tahu kami lebih lanjut tentang kasus-kasus seperti itu di komentar.
CLion sekarang memiliki
beberapa opsi untuk bekerja dari jarak jauh dengan proyek dan debugging. Dari opsi yang sepenuhnya jauh, ketika perakitan dan debugging proyek terjadi pada mesin jarak jauh, ke opsi di mana hanya proyek yang di-debug. Itu untuk kasus kedua, kami menambahkan konfigurasi lain ke CLion -
Remote GDB Server . Berbeda dengan
Remote Debug GDB lama (ya, kami tidak memiliki nama, kami setuju), dalam konfigurasi baru, CLion membangun proyek itu sendiri (mungkin Anda perlu mengkonfigurasi pengaturan lintas-kompilasi), mengunduh file yang dapat dieksekusi ke mesin jarak jauh, dan menjalankan program Anda di bawah gdbserver yang ditentukan. Konfigurasi lama sekarang lebih cocok untuk opsi yang kompleks, ketika kode berada di satu mesin, perakitan di mesin kedua, dan debugging di mesin ketiga. Atau jika kompilasi silang tidak dimungkinkan.
Buka file tajuk / sumber
Ya itu benar! Kami akhirnya menambahkan tindakan terpisah untuk beralih antara file header dan masam. Apa perbedaan utama dari platform lama
Go to Related Symbol ? Faktanya adalah bahwa, sebagai aksi platform umum,
Go to Related Symbol mencoba menjadi sangat akurat dan memilih satu opsi yang paling benar. Ini panjang dan tidak selalu benar dalam kasus C ++. Tindakan
Go to Header / Source yang baru berperilaku berbeda:
- Jika dalam 500 ms tidak ada satu pun opsi yang benar, maka daftar turun bawah opsi yang sesuai muncul, dari mana pengguna dapat memilih yang paling cocok.
- Jika pengguna telah menavigasi dari file ini, file di mana ia menavigasi akan berada di bagian atas daftar.
- Selanjutnya dalam daftar akan ada file dari direktori yang sama dengan nama yang sama.
- Dan kemudian hasil pencarian untuk pencocokan deklarasi dan definisi akan berlanjut.
Perlu dicatat fitur pencarian (karena pengguna kami telah bertemu dengannya) - pencarian sekarang dilakukan pada file yang langsung disertakan / inklusif. Ini adalah batas waktu yang diperlukan agar tidak membingungkan karakter dengan nama yang sama dari target yang berbeda.
Analisis kode
Pemeriksaan baru telah muncul di penganalisis kode di CLion. Ini menangkap situasi ketika fungsi virtual dipanggil dari konstruktor atau destruktor. Mengapa ini buruk sudah
banyak dibahas . Sekarang CLion memperingatkan kasus-kasus seperti ini:
Pemeriksa Ejaan adalah komponen integral dari lingkungan pengembangan terintegrasi. Kita semua membuat kesalahan pengejaan, dan kemudian sulit bagi kolega kita untuk membaca kode dan komentar. Oleh karena itu, ada baiknya ketika IDE menyoroti kesalahan tersebut. Dalam rilis ini, kami telah menyertakan pemeriksaan ejaan dalam file CMake dan komentar dokumentasi format Doxygen:
Kurang kesalahan ejaan - kode yang lebih mudah dibaca!
Konsep dari C ++ 20
Tim kami melakukan banyak upaya dalam mesin bahasa berbasis Clangd. Dan komunitas C ++ global secara aktif mengembangkan Dentang. Dalam rilis ini, kami bergabung - mereka mengambil cabang eksperimental Clang dengan dukungan untuk konsep dari C ++ 20, yang dikembangkan oleh Saar Raz, dan menuangkannya ke cabang Clangd kami. Dengan demikian, kami mendapat sorotan kode dengan konsep dan pemeriksaan dasar penganalisis Dentang di CLion:
Tapi kami tidak berhenti di situ. Dan di engine berbasis Clangd kami, kami menerapkan beberapa kasus penyelesaian otomatis yang bermanfaat, memeriksa penggunaan konsep,
Ganti nama refactoring untuk konsep, navigasi, dan tindakan pencarian.
Pergi ke Definisi dan
Temukan Penggunaan .
Pengisian otomatis untuk parameter template yang tunduk pada batasan:
std::is_same<Other, T> otomatis untuk
std::is_same<Other, T> dan
same_as<T, U> :
Anda dapat membaca lebih lanjut tentang kerja bersama kami tentang konsep-konsep di
blog berbahasa Inggris . Ada juga rekaman video dari laporan CppCon 2019, di mana Saar Raz mempresentasikan implementasi konsepnya di Dentang dan kerja bersama kami tentang dukungan konsep di CLion.
Metrik Cakupan Kode
Cakupan kode adalah peluang yang telah ditunggu dan diminta oleh pengguna CLion. Dalam rilis terakhir, tim AppCode mulai bekerja ke arah ini, dan dalam hal ini kami mengambilnya untuk kasus lintas-platform C ++ yang sudah ada di CLion.
Metrik cakupan kode CLion bekerja melalui integrasi dengan alat llvm-cov / gcov. Dalam hal ini, Anda dapat menjalankan pengujian unit dan konfigurasi reguler, dan sesuai dengan pelaksanaannya, frekuensi eksekusi baris kode tertentu akan dihitung. Hasil beberapa peluncuran dapat, jika diinginkan, diringkas dalam satu umum.
Anda dapat melihat hasilnya langsung di jendela Cakupan khusus:
... atau di gatter kiri di editor.
Nah, dan yang paling penting: agar ini berfungsi, Anda harus melewati opsi kompilasi khusus:
- Untuk GCC:
-fprofile-arcs -ftest-coverage atau --coverage . - Untuk Dentang: baik bendera yang sama dengan GCC, atau
-fprofile-instr-generate -fcoverage-mapping . Perbedaan hanya akan ada dalam metode merakit metrik cakupan.
Mengapa CLion sendiri tidak melewati parameter ini? Sebagian besar karena kami memiliki aturan untuk tidak mengganggu proses kompilasi. Ya, dan tidak selalu jelas ke mana harus melewati parameter ini jika bukan CMake. Tapi sekarang kami sedang memikirkan opsi untuk mengotomatiskan kasus-kasus seperti itu di masa depan (kami memiliki masalah yang sama dengan pembersih).
Anda dapat membaca lebih lanjut tentang opsi kompilasi dan tentang menampilkan metrik di CLion dalam
bantuan online kami.
Perbaikan lainnya
Di antara perbaikan penting lainnya dalam rilis ini:
- Dukungan untuk subsistem WSL2. Pengaturan di CLion sama dengan yang ada di WSL versi pertama.
- Dukungan untuk pemformatan dan aturan penamaan dari Microsoft. Gaya ini tersedia setara dengan Google, LLVM, Qt, GNU, Stroustrup, dan lainnya di Pengaturan / Preferensi | Editor | Gaya Kode | C / C ++.
- Pembaruan Plugin IntelliJ Rust ( pos terperinci di blog berbahasa Inggris kami didedikasikan untuk perubahan ini).
- VCS mendukung pembaruan, antarmuka pengguna, dan perubahan lainnya dari platform IntelliJ.
Demo
Kesimpulannya, video tradisional tentang fitur baru CLion 2019.3 (dalam bahasa Inggris):
Terima kasih sudah membaca sampai akhir! Tentunya Anda memiliki pertanyaan, keinginan, laporan bug, dan hanya pemikiran - kami menunggu mereka di komentar! Seperti biasa, kami akan dengan senang hati menjawab dan mendiskusikan ide-ide Anda.
Tim JetBrains CLion Anda
Dorongan untuk berkembang