CLion 2019.3 : nouvelle version axée sur la performance et la mise en place d’améliorations très attendues
Excellente nouvelle ! CLion 2019.3, la dernière mise à jour majeure de cette année, est maintenant disponible !
L’amélioration des performances de l’EDI et la correction des bugs sont des priorités constantes pour notre équipe. Dans cette mise jour, nous avons principalement accru les performances dans plusieurs domaines, éliminé des blocages de l’interface (la plupart d’entre eux sont maintenant résolus!) et amélioré l’éditeur et les intégrations pour nos utilisateurs !
Pour obtenir cette mise à jour, vous pouvez utiliser l’application Toolbox, un package snap (sous Ubuntu), notre site web ou le correctif mis à jour du dernier build de la version 2019.2.
Vous trouverez ci-dessous la liste des principales améliorations de cette version. Pour une présentation plus détaillée, poursuivez votre lecture :
- Performances de l’EDI
- Mises à jour du débogueur
- Plus d’opportunités dans CMake
- Basculement entre les fichiers Header/Source
- Couverture du code
- Concepts de C++20
Vous pouvez également obtenir une vue d’ensemble des nouveautés avec cette vidéo de Phil Nash :
Performances de l’EDI
Durant ce cycle de mise à jour nous avons particulièrement travaillé sur l’amélioration des performances de la plateforme IntelliJ et de CLion.
Concernant la plateforme IntelliJ, nous avons implémenté plusieurs changements architecturaux significatifs afin d’accélérer le démarrage de l’EDI. Ces modifications incluent notamment :
- Parallélisation d’une partie des processus qui s’exécutaient auparavant de façon séquentielle.
- Réorganisation des classes de manière à accélérer le chargement de la classe initiale.
- Optimisation du chargement des polices sous macOS.
Concernant CLion, nous avons concentré nos efforts sur l’élimination des blocages de l’interface. Si nous ne pouvons pas garantir une absence totale de blocages (notamment pour les projets C++ les plus complexes), la plupart ont été éliminés. Et nous comptons poursuivre nos efforts dans ce sens pour les prochaines versions ! D’autre part, nous avons optimisé l’étape Building/Updating symbols en remaniant une partie des algorithmes sous-jacents. Selon le projet, le CPU et l’environnement, vous pouvez bénéficier d’un gain de temps de 10 à 50 % selon nos calculs.
Notre équipe a également travaillé à l’amélioration des performances en remaniant plusieurs des fonctionnalités principales de l’EDI. Tout d’abord, la refactorisation Rename inclut désormais un mode vous demandant d’abord si vous souhaitez renommer les utilisations non liées au code (telles que les occurrences dans les commentaires et les littéraux de chaîne) avant de lancer une recherche pour toutes les occurrences. Pour ce faire vous devez désactiver le mode in-place de Rename (Settings/Preferences | Editor | General | Refactorings | Enable in-place mode).
Quelle est d’après vous la fonctionnalité la plus utilisée dans tout EDI ou éditeur de texte intelligent ? Vous l’avez sûrement deviné, il s’agit de la saisie automatique du code ! Afin d’accélérer la saisie dans CLion, nous avons implémenté un fournisseur de saisie automatique supplémentaire. Il est basé sur Clangd et donne des résultats plus rapidement pour les projets avec LLVM, Boost, Qt ou Eigen :
En savoir plus sur les résultats.
Mises à jour du débogueur
CLion s’intègre avec les débogueurs GDB et LLDB, et dans cette version nous avons travaillé sur cette intégration pour en améliorer la convivialité et la qualité.
Pour LLDB, nous fournissons la version v9.0 et avons totalement remanié les pretty printers. Par conséquent, les conteneurs standards sont désormais visualisés de façon plus précise. Nous avons aussi amélioré la prise en charge de libc++ sous macOS par rapport à libstdcxx (dites-nous si vous utilisez cette dernière version sous macOS et spécifiez la chaîne d’outils utilisée, de façon à nous permettre d’y apporter des améliorations). Sous Ubuntu, la seule différence réside dans les conteneurs associatifs non ordonnés. Vous trouverez une comparaison détaillée ici.
Pour GDB et LLDB, CLion prend désormais en charge la lecture de .gdbinit/.lldbinit depuis la racine du projet (auparavant CLion ne pouvait lire ces fichiers que dans le répertoire d’accueil de l’utilisateur). Cela vous permet de régler le comportement du débogueur sans affecter les autres projets sur votre machine. Pour activer ce comportement, vous devez autoriser explicitement .gdbinit/.lldbinit dans votre répertoire home :
- Pour GDB :
- Autorisation gobale :
set auto-load local-gdbinit on
add-auto-load-safe-path / - Autorisation par projet :
set auto-load local-gdbinit on
add-auto-load-safe-path C:\work\myproject\.gdbinit
- Autorisation gobale :
- Pour LLDB :
settings set target.load-cwd-lldbinit true
L’un des cas d’utilisation type consiste à fournir des pretty printers personnalisés pour certains types de données dans votre projet :
Et enfin, une nouvelle configuration pour serveur GDB distant a été ajoutée pour rendre possible le débogage à distance via ssh. L’avantage principal par rapport à la configuration précédente de débogage GDB à distance est que CLion charge l’exécutable sur l’hôte distant et y lance automatiquement votre programme sur le gdbserver. Vous trouverez plus de détails à ce sujet dans notre web help. Vous disposez désormais de 3 options pour vous connecter à distance lorsque CLion est exécuté localement– le mode Full Remote (en cas de création de build, exploitation et exécution à distance) et 2 options pour le débogage à distance (lorsque seul le débogage se fait sur un hôte distant).
Plus d’opportunités dans CMake
CMake est connu comme étant le modèle de projet de première classe de CLion. De nombreux utilisateurs de CLion lui font confiance et certains ont même converti leurs projets en CMake pour pouvoir travailler dans CLion. Dans cette version nous avons résolu deux des principales limitations de l’intégration de CMake dans CLion.
Nous nous sommes naturellement appuyés sur le générateur Ninja ! De plus, il est désormais possible d’utiliser tout générateur disponible dans CMake. Il suffit de le transférer dans les options de CMake, dans les paramètres de CMake Profiles :
L’implémentation repose sur l’API de fichier CMake, disponible lorsque CMake 3.15 ou une version plus récente est utilisée.
Nous remercions les nombreux utilisateurs EAP qui ont testé cette fonctionnalité dès sa mise à disposition. Leurs retours nous ont permis de résoudre de nombreux incidents avant la publication officielle.
Nous avons également voulu rendre possible la configuration globale de certains paramètres CMake pour les nouveaux projet créés dans CLion. Par exemple, un modèle pour le chemin de génération ou pour certains paramètres d’environnement. Dorénavant vous pouvez le faire avec les paramètres par défaut de CMake ! Utilisez File | Other Settings | Preferences/Settings for New Projects…
Et enfin, cette nouvelle version résout un problème gênant : si certaines configurations CMake sont invalides et ne se rechargent pas, CLion n’échoue plus et recharge toutes les configurations valides possibles. Le cas d’usage typique pour cela : lorsque votre configuration à distance n’est pas connectée et que vous voulez recharger plusieurs configurations locales. Auparavant, le processus de rechargement échouait, mais désormais les configurations locales sont rechargées avec succès.
Basculement entre les fichiers Header/Source
Pour basculer entre les fichiers header et source, CLion offre désormais une action plus efficace et précise basée sur une approche heuristique : Go to Header/Source. Utilisez-la à la place de l’action Go to Related Symbol plus générale de la plateforme IntelliJ.
La nouvelle action tente de localiser le fichier de destination unique et s’il échoue en 500 ms, elle affiche une fenêtre contextuelle interactive dans laquelle les nouveaux éléments sont ajoutés (et surtout calculés en arrière-plan, afin d’éviter le blocage de l’interface !). Ensuite, vous pouvez sélectionner la destination de la navigation.
La recherche Go to Header/Source repose sur plusieurs heuristiques, par exemple, le fichier sélectionné le plus récemment est toujours en tête de liste et le fichier ayant un nom concordant dans le même répertoire vient ensuite.
La recherche est actuellement limitée aux vues Includers/Includees directes, pour éviter les interférences de symboles identiques provenant de cibles différentes.
Couverture du code
Si cette version porte essentiellement sur la résolution de bugs, la dette technique et les performances, nous avons toutefois ajouté plusieurs nouvelles fonctionnalités. La couverture du code faisant l’objet de nombreuses demandes dans note système de suivi des tickets, nous avons ajouté l’intégration avec les outils llvm-cov/gcov.
Vous pouvez également exécuter des tests unitaires et des configurations régulières avec Coverage, mais il ne faut pas oublier de transférer les options spéciales de compilation de couverture. Cela doit se faire manuellement car CLion ne modifie pas automatiquement vos fichiers CMake et les options de compilation.
Les résultats des mesures peuvent être vérifiés dans une fenêtre d’outils distincte de Coverage ou sont accessibles directement dans l’éditeur – la couverture est représentée par différentes couleurs dans la gouttière de gauche.
Vous trouverez plus de détails sur ce point dans notre webhelp.
Concepts de C++20
Au cours des deux derniers cycles de publication, nous avons expérimenté notre moteur de langage basé sur Clangd. L’idée était de fusionner une autre branche expérimentale – la branche clang de Saar Raz avec prise en charge de Concepts – et d’y ajouter quelques fonctionnalités inédites. Nous avons discuté de cette idée pour la première fois lorsque nous avons rencontré Saar à la conférence Core C++ de Tel Aviv, en mai 2019, et désormais, avec CLion 2019.3, nous sommes prêts à appliquer les résultats de cette collaboration.
Dans CLion, le moteur basé sur Clangd permet désormais d’analyser et de mettre en évidence les concepts C++20 correctement. Il y a également quelques vérifications de code provenant de Clang, et l’inspection Unused concept.
Mais le travail le plus important a porté sur la saisie automatique du code, car CLion peut désormais compléter les paramètres de type de modèle qui sont contraints, ainsi que les types contraints par std::is_base_of<MyBase, T>, std::is_same<Other, T> and same_as<T, U>:
Il prend également en charge la refactorisation Rename, ainsi que les actions de navigation Go to Definition et Find Usages. Vous trouverez des exemples et des instructions d’activation de la prise en charge des concepts de C++20 dans le compilateur, dans notre billet de blog dédié.
Nous tenons à remercier Saar Raz pour son travail remarquable sur Clang et sa collaboration productive avec notre équipe !
Autres correctifs et améliorations
Le correcteur orthographique fait partie intégrante de l’EDI et vous permet de vous assurer que vos commentaires, littéraux de chaîne et documentation soient corrects et lisibles. CLion 2019.3 permet la correction orthographique des fichiers CMake et des commentaires Doxygen :
En plus de WSL, CLion prend désormais en charge WSL2. Le processus de configuration de l’EDI n’a pas changé, toutefois il y a quelques différences au niveau de l’expérience utilisateur entre ces deux sous-systèmes.
La nouvelle inspection de virtual functions called from constructors or destructors a été ajoutée pour identifier les situations dans lesquelles les fonctions virtuelles peuvent avoir accès à des ressources qui ne sont pas encore initialisées ou ont déjà été détruites :
Les règles de formatage et de nommage de Microsoft ont été ajoutées sous forme d’options de style de code prédéfinies, élargissant la liste comprenant les styles Google, LLVM, Qt, GNU, Stroustrup et autres.
Dans la mesure où CLion repose sur la plateforme IntelliJ, des améliorations ont également été apportées à VCS et des dizaines de problèmes liés à l’interface ont été résolus. Pour ceux d’entre vous qui utilisent CLion en tant qu’EDI Rust, nous avons le plaisir de vous informer que le plugin Rust d’IntelliJ a fait l’objet d’une mise à jour importante (nous allons d’ailleurs y consacrer un article de blog, donc restez à l’écoute !).
C’est tout pour le moment ! Nous espérons que la présentation de ces nouveautés vous a donne envie d’essayer la nouvelle version ! N’hésitez pas à nous faire part de vos commentaires !
L’équipe CLion
JetBrains
The Drive to Develop
Auteur de l’article original en anglais : Anastasia Kazakova
Subscribe to JetBrains Blog updates
