Bonjour, Habr! Beaucoup commencent déjà à se préparer pour les vacances du Nouvel An, à acheter des cadeaux, quelqu'un planifie un voyage pour les longues vacances du Nouvel An. Et chez JetBrains, il est encore temps pour nous de publier les versions de produits. Aujourd'hui, je suis pressé de partager avec vous les nouvelles de la sortie récente de notre environnement de développement multiplateforme pour C et C ++ - CLion 2019.3.
Le principal objectif de cette version était, aussi pathétique que cela puisse paraître, la qualité. Nous avons décidé de nous concentrer sur les problèmes qui gênent nos utilisateurs depuis longtemps - tout d'abord, la productivité et la réactivité de l'éditeur, et deuxièmement, les bugs, les imperfections et les fonctionnalités très populaires mais manquantes.
Pour commencer, brièvement sur la chose la plus importante de cette version:
- Améliorations de la vitesse et de la réactivité de l'éditeur, principalement l'auto-complétion implémentée dans notre moteur basé sur Clangd.
- Générateur Ninja dans CMake, paramètres CMake par défaut et autres améliorations du modèle de conception.
- Mises à jour en intégration avec les débogueurs.
- Nouvelle action pour basculer entre les fichiers d'en-tête et les fichiers sour.
- Analyse de code plus précise: une nouvelle vérification des fonctions virtuelles, ainsi que la vérification orthographique dans CMake et dans les commentaires Doxygen.
- Prise en charge des concepts de la norme C ++ 20.
- Mesures de couverture du code.
- WSL2, les conventions de mise en forme et de dénomination de Microsoft, les mises à jour de prise en charge VCS, etc.
Nous parlerons plus en détail ci-dessous, mais si vous êtes prêt à l'essayer maintenant, allez-y et téléchargez la version depuis
notre site Web . Comme d'habitude, un essai gratuit de 30 jours est disponible.
Performance de l'éditeur
À en juger par les statistiques que beaucoup de nos utilisateurs acceptent de nous envoyer, l'action la plus utilisée dans CLion est l'
auto-complétion . C'est sur lui que nous avons décidé de nous concentrer sur cette version pour la rendre plus réactive. Pour ce faire, nous en avons ajouté un de plus, basé sur Clangd, aux fournisseurs de saisie semi-automatique déjà existants dans l'EDI. L'essentiel, c'est que tous les fournisseurs travaillent en parallèle et dès que les premiers résultats sont prêts, CLion affiche une liste déroulante d'options, continuant à charger d'autres options selon les besoins.
Bien sûr, nous voulions comprendre si une telle approche hybride offre des avantages. Les mesures ont montré que sur des projets simples, la vitesse du fournisseur CLion et du fournisseur basé sur Clangd ne diffère pas beaucoup. Mais sur des projets complexes tels que LLVM, Qt, Boost, Eigen, les cent premiers résultats de Clangd apparaissent beaucoup plus rapidement. Jugez par vous-même:
En savoir plus sur les mesures dans un
article séparé sur le blog CLion en anglais.
Parmi les autres améliorations importantes, il convient de noter l'accélération de la plate-forme au moment du lancement de l'IDE. Il a été atteint en parallélisant de nombreux processus au début, en réorganisant les classes chargées au début et en optimisant le chargement des polices sur macOS. Les nombres spécifiques à accélérer dépendent des paramètres de l'environnement, de la voiture, de la plate-forme et d'autres facteurs.
Dans CLion, à notre grand regret, il y a encore des blocages d'interface utilisateur. Nous essayons de les regrouper en fonction du problème d'origine et de résoudre un problème après l'autre. Ainsi, dans cette version, nous avons corrigé les blocages dans les cas d'une vue Usages ouverte, lors du passage à une déclaration, lors du changement de nom de la directive
#include , lors de l'utilisation de miettes de pain et de la suppression sécurisée, ainsi que dans d'autres cas. Les suspensions de l'interface utilisateur restent le problème le plus urgent pour nous, nous continuerons donc certainement ce travail dans les prochaines versions.
Et enfin,
Renommer le refactoring d'accélération . Cette refactorisation peut renommer non seulement l'utilisation du nom dans le code, mais aussi dans les littéraux de chaîne et les commentaires. Mais ce n'est pas toujours nécessaire, et la recherche du nom a été effectuée avant que l'utilisateur IDE n'indique quelles utilisations particulières seraient renommées. Cela a entraîné de longs retards dans la recherche d'un nom populaire. Maintenant, vous pouvez d'abord sélectionner une recherche uniquement par code, puis seulement lancer la recherche elle-même. Pour ce faire, accédez à Paramètres / Préférences | Editeur | Général | Les refactorisations doivent être désactivées «Activer le mode sur place». Dans ce cas, lorsque le refactoring est appelé (Shift + F6 par défaut sur Windows / Linux, ⇧F6 sur macOS), CLion ouvrira immédiatement la boîte de dialogue Renommer, où vous pourrez spécifier les paramètres de recherche:
Améliorations du modèle de conception de CMake
Ici, beaucoup d'entre vous devaient attendre l'annonce de la prise en charge de Makefiles. Mais jusqu'à présent, seule une
approche semi-automatique de leur intégration via la base de données de compilation est disponible. Un support plus natif est toujours en cours de développement, mais dans ce cycle de publication, nous avons fait de grands progrès et nous avons toutes les chances de montrer un nouveau support pour la prochaine version 2020.1, vers la fin de mars 2020.
Mais nous avons profité de l'occasion tant attendue pour prendre en charge CMake - la possibilité de spécifier n'importe quel générateur CMake, y compris le générateur
Ninja tant attendu par les utilisateurs! Auparavant, nous utilisions des Makefiles et des générateurs similaires, car nous analysions les fichiers résultants (plus précisément, ils étaient
-G "CodeBlocks - Unix Makefiles" , et sur Windows
-G "CodeBlocks - MinGW Makefiles" et
-G "CodeBlocks - NMake Makefiles" ) Vous pouvez maintenant spécifier n'importe quel générateur dans le profil CMake dans CLion:
Cela n'est possible que lorsque vous utilisez CMake version 3.15 et supérieure, car il est implémenté via l'API de fichier CMake et fonctionne sur toutes les plates-formes, à distance, pour WSL / WSL2.
Je note que des générateurs tels que Xcode et Visual Studio sont multi-générateurs, c'est-à-dire qu'ils génèrent des fichiers pour tous les types d'assemblys (Debug, Release, etc.), mais CLion n'utilisera que le type d'assembly spécifié dans Profil CMake.
Cette version a également introduit les
paramètres par défaut de CMake . Cela signifie que pour tous les nouveaux projets dans CLion, vous pouvez utiliser les mêmes paramètres prédéfinis, tels que le générateur CMake ou le répertoire pour générer CMake. Les paramètres peuvent être spécifiés dans Fichier | Autres paramètres | Paramètres des nouveaux projets ...
Parmi les améliorations importantes apportées au modèle de projet CMake, il convient de souligner la possibilité de recharger des configurations valides, même si d'autres non valides sont présentes dans le projet. Cela peut être utile si vous avez configuré plusieurs configurations distantes qui ne sont actuellement pas disponibles, mais que vous souhaitez recharger au moins les configurations locales.
Mise à jour de l'intégration du débogueur
Dans les débogueurs, nous avons décidé de corriger les problèmes et les carences qui concernent le plus nos utilisateurs. Tout d'abord, CLion lit maintenant
.gdbinit / .lldbinit dans le répertoire du projet . Ceci est utile si vous souhaitez personnaliser certains paramètres du débogueur ou ajouter de jolies imprimantes, mais uniquement pour un projet spécifique. Auparavant, vous deviez spécifier ces paramètres dans les fichiers de configuration du débogueur dans le répertoire utilisateur. Vous pouvez maintenant configurer ces paramètres spécifiques au projet. Mais pour que cela fonctionne, vous devez activer ce comportement dans le débogueur lui-même dans les paramètres au niveau du répertoire utilisateur (lisez comment faire cela pour
GDB et comment
LLDB ).
L'intégration avec LLDB est disponible sur Linux et macOS. Dans la nouvelle version, nous avons mis à niveau la LLDB intégrée vers la version 9.0, et en même temps examiné globalement toutes les jolies imprimantes intégrées. Grâce à cela, les performances des conteneurs standard sur les deux plates-formes se sont considérablement améliorées. Des comparatifs détaillés sont disponibles sur notre
blog en anglais . Il convient de noter que sur la plate-forme macOS, la
bibliothèque libc ++ gère bien mieux que
libstdcxx . Cela semble correspondre à la popularité de ces bibliothèques sur cette plate-forme, mais si vous utilisez
libstdcxx sur macOS, veuillez nous en dire plus sur ces cas dans les commentaires.
CLion dispose désormais de
plusieurs options pour travailler à distance avec un projet et déboguer. De l'option complètement distante, lorsque l'assemblage et le débogage du projet se produisent sur une machine distante, aux options où seul le projet est débogué à distance. Voilà pour le deuxième cas, nous avons ajouté une autre configuration à CLion -
Remote GDB Server . Contrairement au
débogage à distance GDB de longue date (oui, nous n'avions pas de nom, nous sommes d'accord), dans la nouvelle configuration, CLion construit le projet lui-même (peut-être vous devez configurer les paramètres de compilation croisée), téléchargez le fichier exécutable sur la machine distante, et exécute votre programme sous le gdbserver spécifié. L'ancienne configuration est désormais plus adaptée aux options complexes, lorsque le code se trouve sur une machine, l'assemblage sur la seconde et le débogage sur la troisième. Ou si la compilation croisée n'est pas possible.
Aller aux fichiers d'en-tête / source
Oui, c'est vrai! Nous avons finalement ajouté une action distincte pour basculer entre les fichiers d'en-tête et les fichiers sour. Quelle est la principale différence avec l'ancienne plateforme
Aller au symbole associé ? Le fait est que, en tant qu'action de plate-forme courante,
Aller au symbole associé essaie d'être très précis et de choisir l'une des options les plus correctes. C'est à la fois long et pas toujours correct dans le cas de C ++. La nouvelle action
Aller à l'en-tête / source se comporte différemment:
- Si, dans les 500 ms, il n'y a pas une seule option correcte, une liste déroulante d'options appropriées apparaît, à partir de laquelle l'utilisateur peut sélectionner la plus appropriée.
- Si l'utilisateur a déjà navigué à partir de ce fichier, le fichier vers lequel il naviguera sera en haut de la liste.
- Plus loin dans la liste, il y aura des fichiers du même répertoire avec le même nom.
- Et puis les résultats de recherche pour les déclarations et définitions correspondantes continueront.
Il convient de noter la fonction de recherche (car nos utilisateurs l'ont déjà rencontrée) - la recherche est désormais effectuée sur des fichiers directement inclus / inclusifs. C'est un délai qui est nécessaire pour ne pas confondre les personnages du même nom avec des cibles différentes.
Analyse de code
Une nouvelle vérification est apparue dans l'analyseur de code dans CLion. Il détecte les situations où des fonctions virtuelles sont appelées à partir de constructeurs ou de destructeurs. Pourquoi cela est mauvais a déjà
été beaucoup discuté . Maintenant, CLion met en garde contre de tels cas:
Le correcteur orthographique fait partie intégrante d'un environnement de développement intégré. Nous commettons tous des fautes d'orthographe, puis il est difficile pour nos collègues de lire le code et les commentaires. Par conséquent, c'est bien lorsque l'EDI met en évidence de telles erreurs. Dans cette version, nous avons inclus la vérification orthographique dans les fichiers CMake et les commentaires de documentation sur le format Doxygen:
Moins d'erreurs d'orthographe - code plus lisible!
Concepts de C ++ 20
Notre équipe met beaucoup d'efforts dans le moteur de langage basé sur Clangd. Et la communauté mondiale C ++ développe activement Clang. Dans cette version, nous avons uni nos forces - nous avons pris la branche expérimentale de Clang avec le support des concepts de C ++ 20, qui est développé par Saar Raz, et l'avons versée dans notre branche de Clangd. Ainsi, nous avons obtenu la mise en évidence du code avec des concepts et des vérifications de base de l'analyseur Clang dans CLion:
Mais nous ne nous sommes pas arrêtés là. Et dans notre moteur basé sur Clangd, nous avons implémenté quelques cas utiles d'auto-complétion, vérifiant l'utilisation d'un concept,
renommant le refactoring des concepts, la navigation et les actions de recherche
Aller à la définition et
trouver des utilisations .
Saisie semi-automatique pour les paramètres de modèle soumis à des restrictions:
std::is_same<Other, T> automatique pour
std::is_same<Other, T> et
same_as<T, U> :
Vous pouvez en savoir plus sur notre travail conjoint sur les concepts dans le
blog en anglais . Il existe également un enregistrement vidéo du rapport de CppCon 2019, dans lequel Saar Raz a présenté sa mise en œuvre de concept à Clang et notre travail conjoint sur le support de concept dans CLion.
Mesures de couverture du code
La couverture du code est une opportunité que les utilisateurs de CLion attendaient et demandaient. Dans la dernière version, l'équipe AppCode a commencé à travailler dans ce sens, et nous l'avons repris pour les cas de C ++ multiplateforme déjà dans CLion.
Les mesures de couverture du code CLion fonctionnent grâce à l'intégration avec les outils llvm-cov / gcov. Dans ce cas, vous pouvez exécuter à la fois des tests unitaires et des configurations régulières, et en fonction de leur exécution, la fréquence d'exécution de certaines lignes de code sera calculée. Les résultats de plusieurs lancements peuvent, si vous le souhaitez, être résumés en un seul général.
Vous pouvez voir les résultats directement dans une fenêtre de couverture spéciale:
... ou à gauche dans l'éditeur.
Eh bien et surtout: pour que cela fonctionne, vous devez passer des options de compilation spéciales:
- Pour GCC:
-fprofile-arcs -ftest-coverage ou --coverage . - Pour Clang: soit les mêmes indicateurs qu'avec GCC, soit
-fprofile-instr-generate -fcoverage-mapping . Les différences ne concerneront que la méthode d'assemblage des mesures de couverture.
Pourquoi CLion lui-même ne transmet-il pas ces paramètres? Principalement parce que nous avons une règle pour ne pas interférer avec le processus de compilation. Oui, et on ne sait pas toujours où passer ces paramètres en cas de non CMake. Mais maintenant, nous réfléchissons à des options pour automatiser de tels cas à l'avenir (nous avons un problème similaire avec les désinfectants).
Vous pouvez en savoir plus sur les options de compilation et sur l'affichage des métriques dans CLion dans notre
aide en ligne .
Autres améliorations
Parmi les autres améliorations importantes de cette version:
- Prise en charge du sous-système WSL2. Les paramètres de CLion sont les mêmes que ceux de la première version de WSL.
- Prise en charge des règles de formatage et de dénomination de Microsoft. Ce style est disponible sur un pied d'égalité avec Google, LLVM, Qt, GNU, Stroustrup et autres dans Paramètres / Préférences | Editeur | Style de code | C / C ++.
- Mises à jour du plug-in IntelliJ Rust (un article détaillé sur notre blog en anglais est dédié à ces changements).
- VCS prend en charge les mises à jour, l'interface utilisateur et d'autres modifications de la plate-forme IntelliJ.
Démo
En conclusion, une vidéo traditionnelle sur les nouvelles fonctionnalités de CLion 2019.3 (en anglais):
Merci d'avoir lu jusqu'au bout! Vous avez sûrement des questions, des souhaits, des rapports de bugs et juste des pensées - nous les attendons dans les commentaires! Comme toujours, nous serons heureux de répondre et de discuter de vos idées.
Votre équipe JetBrains CLion
La volonté de se développer