CLion 2019.2 dirilis: dukungan pengembangan tertanam, debugger untuk MSVC, mencari file header yang tidak digunakan

Halo, Habr!

Musim panas di luar jendela terbang bagi kami hampir tanpa terasa, karena kami telah mencurahkan semua bulan ini untuk mengerjakan rilis baru 2019.2 dari lingkungan pengembangan lintas platform kami untuk C ++ - CLion. Kami berhasil melakukan banyak hal: melakukan Hackathon internal, mencoba ide-ide baru, dan membawa sejumlah koreksi dan fitur baru ke rilis langsung. Tetapi hal pertama yang pertama.



Singkatnya, dalam rilis ini kami:

• Kami terus memperbaiki dukungan untuk pengembangan sistem tertanam: kemampuan debugging baru dan perangkat tambahan muncul.
• Debugger eksperimental untuk MSVC telah dibawa ke kualitas yang dapat diterima.
• Kami sepenuhnya menulis ulang verifikasi kode pada Unused Includes pada clangd, menambahkan kemampuan untuk mengkonfigurasi berbagai strategi.
• Petunjuk yang diterapkan untuk argumen panggilan fungsi dan lambdas untuk meningkatkan keterbacaan kode.
• Kami melakukan Hackathon dalam tim untuk meningkatkan produktivitas, menghasilkan banyak pendekatan baru dan berhasil menerapkan beberapa peningkatan.
• Kami menerapkan penyorotan sintaks untuk lebih dari 20 bahasa, dibangun di plugin Shell Script, dan memperbarui plugin Rust.

Ini, tentu saja, tidak semuanya . Kami akan berbicara lebih detail di bawah ini, tetapi jika Anda siap untuk mencobanya sekarang, masuk dan unduh build dari situs web kami . Seperti biasa, percobaan gratis selama 30 hari tersedia.

Fitur baru untuk pengembangan tertanam

Dalam rilis sebelumnya, untuk beberapa alasan, banyak yang berpikir bahwa kami hanya fokus pada papan STM32. Ini, tentu saja, adalah salah satu pasar yang paling menarik dan luas dalam banyak penelitian (termasuk domestik kami), tetapi kami sekarang mencoba untuk memecahkan masalah yang lebih umum. Sebagai contoh, kami memperluas kemampuan debug pada berbagai papan dari CLion.

Sebelumnya, satu-satunya pilihan adalah konfigurasi untuk debugger OpenOCD - OpenOCD Download & Run. Sekarang satu lagi telah muncul - Embedded GDB Server. Bahkan, jika papan mendukung debugging melalui beberapa server GDB yang kompatibel, Anda dapat men-debug itu melalui CLion. Konfigurasi mencakup kasus-kasus seperti OpenOCD, ST-Link GDB Server, Segger J-Link GDB Server, QEMU dan banyak lagi.



Cukup membuat dan mengonfigurasi konfigurasi yang sesuai - tentukan jalur ke server GDB, argumen yang Anda berikan, mungkin beberapa pengaturan lebih lanjut. Sekarang jalankan debugging dalam konfigurasi ini, dan Anda dapat men-debug di papan langsung dari CLion!

Ada satu batasan penting yang sekarang mempengaruhi kedua konfigurasi untuk debugging embedded system - keduanya saat ini hanya bekerja dengan proyek-proyek di CMake. Di masa depan, kami berencana untuk menambahkan kemampuan menjalankannya untuk model desain khusus ( CPP-16079 ).

Untuk konfigurasi debug yang ada pada sistem embedded (Embedded GDB Server dan OpenOCD Download & Run), rilis baru sekarang memiliki kemampuan untuk melihat perangkat saat debugging. Secara umum, periferal ditentukan untuk perangkat keluarga ARM dalam file berformat .svd . Spesifikasi ini sekarang dapat dimuat ke dalam CLion dan melihat periferal yang dipilih secara langsung di jendela debugger:



Semua periferal masih tersedia dalam mode baca-saja, sementara ada pencarian berdasarkan nama, kemampuan untuk melihat nilai dalam mode yang berbeda (heksadesimal, desimal, oktal, dan biner). Anda dapat membaca lebih banyak tentang ini di blog kami (dalam bahasa Inggris).

Debugger eksperimental untuk MSVC

Anda membacanya dengan benar - dalam rilis 2019.2, CLion memperkenalkan debugger eksperimental untuk kode yang dikompilasi menggunakan MSVC! Sekarang mari kita memahami sedikit lebih detail dan teratur.

Untuk waktu yang lama di CLion, Anda dapat menggunakan tidak hanya MinGW dan Cygwin toolchain, tetapi juga Visual Studio saat berkembang di platform Windows. Anda menentukan jalur ke VS yang diinstal di CLion, dan dari sana kami mengambil kompiler dan skrip MSVC untuk mengkonfigurasi lingkungan. Tapi ada masalah dengan debugger untuk waktu yang lama. Faktanya adalah bahwa debugger yang digunakan Visual Studio sendiri adalah milik. Sederhananya, tidak ada tempat kecuali alat Microsoft yang dapat digunakan di bawah lisensi. Ada teknologi alternatif - dbgeng.dll , di mana CDB dan WinGDB debugger diimplementasikan. Hal pertama yang kami uji adalah dia. Tetapi bagi kami tampaknya untuk menangani sejumlah crash kritis dan kinerja yang buruk pada biner dengan sejumlah besar file PDB tidak terlalu menjanjikan (walaupun kami mencoba pada awalnya). Dan ternyata ada opsi ketiga - untuk mengimplementasikan debugger di atas LLDB. Sudah ada prestasi, dan kami hanya harus melanjutkan pekerjaan ini. Apa yang kami lakukan! Omong-omong, kami telah menempatkan semua perubahan kami (kecuali untuk dukungan visualisator data asli untuk saat ini) di wizard LLVM.

Bagaimana cara mengaktifkan? Seperti yang sudah saya tulis, peluangnya masih eksperimental. Masih terlalu dini untuk memanggil debugger sepenuhnya, ia memiliki banyak keterbatasan dan kekurangan, dan kinerja memerlukan optimalisasi yang signifikan. Fitur eksperimental ini diaktifkan dalam dialog Pemeliharaan ( Shift+Ctrl+Alt+/ di Linux / Windows, ⌥⇧⌘/ di macOS) | Fitur eksperimental | cidr.debugger.lldb.windows . Sekarang debugger baru tersedia untuk toolchain Visual Studio:



Debugger memiliki dukungan awal untuk visualisator asli, keduanya disertakan dengan studio, dan kustomisasi kustom yang ditemukan dalam proyek. Untuk saat ini, fitur tersebut memerlukan penyertaan eksplisit dalam pengaturan: Pengaturan | Bangun, Eksekusi, Penempatan | Tampilan Data Debugger | Aktifkan penyaji NatVis untuk LLDB. Di salah satu pembaruan pertama, kami berencana untuk memperbaiki beberapa masalah kritis dengan visualisator dan kemudian mungkin menyalakannya secara default.



Jika Anda berencana untuk mencoba debugger eksperimental baru, kami sarankan Anda membiasakan diri dengan daftar keterbatasan dan masalah yang diketahui di blog kami .

Peningkatan debugger lainnya

Selain debugger eksperimental baru, kami membuat sejumlah peningkatan lainnya:

• Di konsol GDB / LLDB bawaan, di jendela debugger di CLion, pelengkapan otomatis perintah debugger sekarang berfungsi (gunakan Tab atau Ctrl+Space ).
• String breakpoint sekarang divalidasi dengan cepat , dan statusnya diperbarui dan ditampilkan kepada pengguna dalam bentuk ikon yang sesuai. Jenis yang paling menarik adalah Invalid , yang ditambahkan untuk mengidentifikasi breakpoint yang tidak tersedia dalam kode yang dapat dieksekusi saat ini atau yang tidak ada simbol debugging (dalam hal ini, setelah memuatnya, status breakpoint akan diperbarui secara otomatis):
  
• Saat melihat memori dalam debugger (Memory View) di versi baru, menjadi mungkin untuk beralih ke alamat arbitrer (dengan alamat numerik atau nama variabel / alamat), serta menghadirkan memori dalam format ASCII:
  

Perbaikan Editor Kode

Ada beberapa peningkatan besar di bidang ini. Pertama, kami benar-benar menulis ulang pemeriksaan kode Termasuk yang Tidak Digunakan dan menyalakannya secara default. Sebelumnya, itu juga ada di sana, tetapi memberikan sejumlah besar positif palsu, jadi kami mematikannya secara default. Mengapa ini menjadi lebih baik? Kami sepenuhnya menulis ulang verifikasi berdasarkan pada alat tambahan kedua untuk kode parsing, yang, pada gilirannya, didasarkan pada Dentang. Jadi ini adalah batasan yang jelas - versi baru hanya akan berfungsi jika Clangd tidak dinonaktifkan untuk Anda (secara default diaktifkan). Tetapi sekarang, dalam memeriksa untuk Unused Includes, beberapa strategi telah muncul, di antaranya Anda dapat memilih:

Secara default, Detect tidak langsung digunakan digunakan , yang pada dasarnya paling dekat dengan prinsip terkenal Sertakan Apa yang Anda Gunakan , yaitu, jika deklarasi dari file header tidak digunakan secara langsung dalam file ini, maka file header tersebut ditandai sebagai tidak digunakan.

Dalam pengaturan inspeksi (Pengaturan / Preferensi | Editor | Inspeksi | C / C ++ | Kode yang tidak digunakan | Tidak digunakan termasuk direktif), Anda juga dapat memilih apakah akan menjalankan pemeriksaan di file header sendiri. Benar, ini hanya akan berfungsi di file header di mana #pragma atau penjaga header ada. Penting juga untuk diketahui bahwa jika ada kesalahan kompilasi dalam file sumber, maka pemeriksaan tidak akan menampilkan file yang tidak digunakan.

Sejak rilis terakhir, CLion telah mendukung ClangFormat sebagai alat pemformatan kode alternatif, selain yang terintegrasi. Dalam versi ini, kami menambahkan skema JSON bawaan untuk file konfigurasi format .clang. Dan berkat ini, kami dapat menambahkan beberapa fitur yang mungkin berguna bagi mereka yang akan memodifikasi file format .clang di CLion:

• Pelengkapan otomatis telah muncul untuk opsi dan nilainya.
• Di jendela penyelesaian otomatis untuk opsi, sekarang ada deskripsi opsi.
• Jendela dokumentasi Dokumentasi Cepat ( Ctrl+Q pada Windows / Linux, F1 pada macOS) menampilkan dokumentasi untuk opsi dan artinya, dengan contoh.
• Validasi opsi untuk nilai yang valid ditambahkan.

Kiat untuk Argumen

Bagaimana jika fungsi ini ditulis (mungkin bukan oleh Anda) sehingga 3 bilangan bulat diteruskan sebagai argumen? Bagaimana memahami dengan pemanggilan fungsi apa arti nilai yang ditransfer? Tentu saja, Anda dapat melihat tanda tangan fungsi di jendela dokumentasi, pergi ke definisi fungsi atau memanggil informasi parameter (Info Parameter). Dan jika Anda tidak melakukan tindakan eksplisit ini?

Dalam versi CLion 2019.2, tooltips untuk argumen muncul - saat memanggil fungsi, lambda, konstruktor, daftar inisialisasi, atau saat menggunakan makro, CLion menampilkan nama parameter sebelum argumen dilewati:
Petunjuk ditunjukkan dalam kasus-kasus ketika benar-benar sulit untuk memahami nilai-nilai apa yang dilewatkan ke parameter mana, yaitu, jika literal atau ekspresi dengan lebih dari satu operan digunakan sebagai argumen. Lebih detail di posting blog .

Performa

Tentu saja, kita sering ditanya tentang peningkatan kinerja. Saya ulangi, bagi kami ini adalah tugas yang paling prioritas, tetapi ternyata tidak ada banyak perubahan poin, dan yang global membutuhkan waktu lebih dari 1-2 siklus rilis. Sekarang ada beberapa perubahan besar dalam pekerjaan. Pada dasarnya, mereka terkait dengan bagaimana parser di CLion berinteraksi dengan arsitektur platform (yang tidak selalu menghitung bahwa kode penyelesaian panjang tersembunyi di balik tindakan sederhana, dalam kasus C ++).

Musim panas ini, tim dan saya memutuskan untuk mengadakan Hackathon internal untuk mengidentifikasi tempat-tempat yang paling rentan dalam arsitektur dan platform CLion, mencoba ide-ide baru yang berani dan menguji beberapa hipotesis lama. Kami menyukai hasilnya. Jika memungkinkan, kami berencana untuk membawa beberapa ide baru ke rilis pada 2019.3.

Tetapi rilis 2019.2 tidak dibiarkan tanpa peningkatan kinerja:

• Kami menyingkirkan banyak pelambatan dan macet di refactoring Ganti Nama Di Tempat.
• Peningkatan kinerja pelengkapan otomatis untuk ekspresi yang berkualitas.
• Dalam kasus pekerjaan jarak jauh, kami mengurangi jumlah operasi I / O, yang secara signifikan mempercepat pengumpulan informasi tentang kompiler, dan, karenanya, kecepatan pengunduhan proyek CMake.
• Dan peningkatan lainnya.

Bukan hanya C ++

Dari platform IntelliJ di CLion 2019.2, banyak perbaikan telah dilakukan untuk bekerja dengan bahasa lain.

Penyorotan sintaks lebih dari 20 bahasa sekarang disediakan oleh tata bahasa TextMate (daftar lengkap bahasa dapat ditemukan di Pengaturan / Preferensi | Editor | Bundel TextMate). Tentu saja, jika untuk bahasa ini ada dukungan tambahan dalam CLion (Python, JavaScript, HTML, Objective-C, SQL), maka itu akan digunakan, tetapi untuk bahasa seperti Ruby, penyorotan paling sederhana dapat berguna:



Seringkali dalam proyek C ++ ada berbagai skrip . Plugin Shell Script sekarang dibangun ke dalam CLion. Ini tidak hanya menyediakan penyorotan kode, tetapi juga pelengkapan otomatis dan penggantian nama teks:



Plugin Rust telah menerima banyak pembaruan bermanfaat. Dari alat ekspansi makro eksperimental baru (Pengaturan / Preferensi | Bahasa & Kerangka | Karat | Perluas makro deklaratif) hingga fragmen kode Duplikat , berbagai perbaikan cepat baru dan pelengkapan otomatis di debugger dalam Evaluasi Evaluasi . Ngomong-ngomong, CLionlah yang menggunakan plugin ini paling banyak sekarang di antara semua IDE dari JetBrains!

Demo

Video tradisional tentang fitur baru CLion 2019.2 (dalam bahasa Inggris):


Itu saja untuk sekali. Terima kasih sudah membaca sampai akhir! Pertanyaan, keinginan, laporan bug dan hanya pemikiran yang diungkapkan dalam komentar! Kami, seperti biasa, akan dengan senang hati menjawab.

Tim JetBrains CLion Anda
Dorongan untuk berkembang