CLion 2019.1 est disponible avec le développement embarqué, ClangFormat, une vue de la mémoire, l’injection de langages, des thèmes personnalisés et bien plus encore
Nous avons d’excellentes nouvelles ! Nous avons réalisé la première mise à jour majeure de CLion cette année !
Pour procéder immédiatement à la mise à jour, utilisez l’application Toolbox, un package snap (sous Ubuntu), notre site Web ou un correctif de la dernière build de 2018.3. N’attendez plus ! 
Comme annoncé plus tôt, les points sur lesquels nous nous concentrons cette année sont les performances de l’EDI, la généralisation du recours à Clangd et le développement embarqué. Cette mise à jour a permis de progresser dans les trois domaines :
- Clangd gère désormais le surlignage de code, fournit des messages d’erreur plus détaillés et exécute de nouvelles inspections.
- Le moteur de langage de CLion a été amélioré, avec notamment de meilleures performances à tous les niveaux de l’EDI et des refactorisations plus précises.
- Nous avons pris plusieurs mesures pour vous aider à gérer efficacement le développement embarqué dans CLion.
- Adaptez CLion à votre style de codage : ClangFormat, conventions de nommage C/C++ et style des header guards.
- Des cibles de build indépendantes du modèle de projet et des configurations d’exécution/débogage sont désormais disponibles et particulièrement utiles pour les projets de base de données de compilation.
- Principales améliorations du débogueur :
- Possibilité d’injecter des langages.
- Égayez votre EDI avec des thèmes de couleur personnalisés !
- Le plug-in Rust a été mis à jour.
- Parmi les autres améliorations, citons la toute nouvelle fenêtre contextuelle Recent Locations, une amélioration pour les programmeurs de plugin, et bien plus encore.
Poursuivez votre lecture pour avoir plus de détails et regardez cette courte vidéo de présentation des nouveautés réalisée par Phil Nash :
Nous vous invitons à télécharger la version d’essai gratuite sur 30 jours pour évaluer toutes ces nouvelles fonctionnalités.
Intégration élargie avec le moteur de langage basé sur Clangd
Notre objectif d’intégration plus large avec Clangd est toujours d’actualité et nous avons donc concentré nos efforts sur le développement de notre moteur de langage complémentaire basé sur Clangd. Partout où cela était possible, que ce soit en termes de fonctionnalités ou de performances, nous avons transféré des actions dans ce moteur, tout en laissant la possibilité (pour l’instant) d’utiliser le moteur de CLion pour ces actions.
Du point de vue de l’utilisateur, nous constatons que cela rend l’éditeur plus réactif. Nous avons également poussé plus loin l’intégration de Clangd en l’utilisant pour identifier les zones qui nécessitent des correctifs rapides. Cela signifie que le moteur de langage basé sur Clangd permet non seulement d’identifier les violations potentielles du code et de renvoyer une erreur ou un avertissement, mais également de préciser l’emplacement nécessitant un correctif rapide. Remarque : actuellement le correctif rapide est fourni par CLion.
Cette deuxième étape présentait toutefois quelques inconvénients et, par conséquent, quelques correctifs rapides ont été retirés temporairement (CPP-15243).
Entre autres choses, le module d’annotation d’erreurs a été amélioré et peut désormais renvoyer un message d’erreur plus détaillé provenant de Clang. Cela s’avère particulièrement utile pour le débogage de résolutions de surcharge ayant échoué, car Clang peut fournir une explication plus détaillée de l’échec de la substitution :
Notre équipe travaillant sur la prise en charge du langage C++ se penche également sur les vérifications de code propres à CLion et leur implémentation dans Clangd. Dans cette version, il s’agit de la vérification Member function can be static qui analyse le corps de la méthode, tout en essayant de déterminer si elle dépend de this ou pas :
Améliorations du moteur de langage de CLion
Performances de l’EDI
Même si nous travaillons sur le moteur basé sur Clangd, nous poursuivons notre effort d’amélioration de notre propre moteur de langage. Tout d’abord, nous tenons à améliorer les performances de l’EDI, là où Clangd ne peut pas encore être appliqué, et ensuite, nous avons accru la précision des refactorisations qui ne peuvent toujours pas être transférées vers le moteur Clangd, tout du moins pas en l’état actuel.
Mais surtout, nous avons réduit le temps d’indexation initial lorsque vous créez un projet ou l’ouvrez pour la première fois. L’idée générale est que CLion peut désormais réutiliser les symboles déjà créés pour d’autres projets ouverts récemment, à condition qu’ils soient adaptés au projet en cours. Les bibliothèques STL ou Boost sont des cas typiques, ainsi que toute autre bibliothèque personnalisée et utilisée fréquemment dans le projet en cours ou les nouveaux projets. Nous prévoyons de revenir sur cette fonctionnalité pour étendre encore plus ses possibilités.
Refactorisations plus précises
Nous avons passé les refactorisations au peigne fin et les avons mises à jour une par une, et nous avons notamment pu travailler sur Extract. Afin de garantir des résultats précis, nous nous sommes assuré que cette refactorisation respecte le qualificateur d’espace de nom std::, la spécialisation et les paramètres du modèle, ainsi que les alias de type.
La refactorisation Rename a également fait l’objet d’une attention particulière de notre part. Désormais, lorsqu’elle est appelée sur un fichier, la classe Rename ne déclenche plus silencieusement la classe associée/struct rename, mais affiche une fenêtre contextuelle proposant cette option. Et inversement !
D’autre part, lorsque le fichier d’en-tête est renommé, les header guards sont mis à jour en conséquence si ils sont utilisés dans ce fichier et le modèle de style des header guards inclut le nom du fichier d’en-tête.
Premiers pas vers le développement embarqué
Si vous développez du code pour les cartes STMicroelectronics, vous serez content d’apprendre que CLion s’intègre désormais avec STM32CubeMX :
- Le nouvel assistant de projet de CLion vous suggère de créer un projet STM32CubeMX (.ioc) ou vous pouvez ouvrir un projet existant de ce type dans CLion.
- Par la suite, vous pouvez démarrer STM32CubeMX directement depuis CLion à tout moment pour mettre à jour les paramètres de la carte et générer du code.
- CLion génère également le fichier CMake adapté à votre projet .ioc et vous demande de sélectionner la configuration de la carte.
Si vous avez déjà essayé le plugin OpenOCD + STM32CubeMX, cette fonctionnalité est très similaire, car nous avons désormais intégré la version mise à jour de ce plugin dans CLion.
La deuxième partie du plugin est particulièrement intéressante pour le développement embarqué, car elle assure l’intégration avec le débogueur Open On-Chip. Utilisez le nouveau modèle de configuration Run/Debug, « OpenOCD Download and Run » pour déboguer votre microcontrôleur.
Vous trouverez plus d’informations sur l’intégration et la configuration préalable dans cet article de blog détaillé.
Adaptez CLion à votre style de codage
ClangFormat
L’outil ClangFormat est si populaire auprès des programmeurs C/C++ que certains le considèrent comme un standard. Le plus souvent, les projets open source stockent un fichier de configuration .clang-format dans leur référentiel. Désormais, lorsque vous ouvrez ce type de projet dans CLion, l’EDI détecte le fichier de configuration et propose de basculer vers ClangFormat. Vous l’aurez compris, ClangFormat est désormais intégré dans CLion et constitue une solution alternative de formatage ! Cela concerne toutes les actions de l’EDI, vous pouvez donc l’utiliser largement.
Vous trouverez également un module de sélection par EDI pour ClangFormat dans la section Settings/Preferences | Editor | Code Style. Vous trouverez plus de détails à ce sujet dans cet article de blog consacré à ce sujet.
Convention de nommage en C/C++
PascalCase pour les classes et les structs, camelCase pour les fonctions membres et les variables, SCREAMING_SNAKE_CASE pour les macros et les constantes, snake_case pour les fonctions globales, « E » en préfixe pour tous les types d’énumération – pour ne citer que les conventions de nommage les plus connues. CLion compatit avec votre douleur et fournit désormais les paramètres correspondants dans la section Settings/Preferences | Editor | Code Style | C/C++ | Naming Convention, et respecte cette sélection dans toutes les opérations de saisie automatique et de génération de code, dans les actions de refactorisation et les correctifs rapides.
Vous pouvez également sélectionner un style de nommage (entre autres paramètres de style de code) à partir d’un profil prédéfini : Google, LLVM, Qt et d’autres sont disponibles. Ou bien vous pouvez activer l’inspection Inconsistent Naming pour que l’EDI vous avertisse en cas de noms problématiques et suggère un nom plus précis et un correctif rapide pour en remplacer toutes les utilisations.
Style Header Guards
Qu’utilisez-vous habituellement dans les fichiers d’en-tête – pragma ou header guards ? Par défaut, CLion génère des header guards (vous pouvez modifier le modèle de fichier d’en-tête pour utiliser pragma dans la section Settings/Preferences | Editor | File and Code Templates). Si vous préférez les header guards, vous aurez le plaisir d’apprendre que CLion 2019.1 permet désormais de configurer leur style :
Le modèle prend en charge la syntaxe Apache Velocity et utilise des variables prédéfinies, telles que ${PROJECT_NAME}, ${PROJECT_REL_PATH}, ${FILE_NAME}, ${EXT}, etc. Si vous souhaitez utiliser un style plus standard, sélectionnez l’une des options de style prédéfinies (comme pour les conventions de nommage).
Cibles de build personnalisées et configurations run/debug
Récemment nous avons eu de nombreuses demandes pour mettre à disposition une commande personnalisée de création de projets accessible dans l’EDI. Nous avons également eu beaucoup de demandes d’options d’exécution/débogage du code binaire dans l’EDI pour diriger la configuration Run/Debug vers l’exécutable personnalisé. Cela serait particulièrement utile pour les projets de base de données de compilation qui sont pris en charge dans CLion (et peuvent être extraits depuis quasiment tout système de build). Et c’est donc exactement ce que nous avons fait dans CLion 2019.1.
Pour créer votre projet avec une commande personnalisée, créez une cible de build personnalisée dans la section Settings/Preferences | Build, Execution, Deployment | Custom Build Targets où vous fournirez des commandes dans les champs Toolchain et Build/Clean :
Pour exécuter ou déboguer une configuration personnalisée dans CLion, paramétrez la configuration Custom Build Application dans Run | Edit Configurations…, où vous pouvez fournir une cible personnalisée, un exécutable, les arguments du programme, etc.
Vous trouverez plus de détails sur la procédure à suivre dans notre webhelp.
Améliorations du débogueur
Vue de la mémoire
À partir de CLion 2019.1, vous pouvez faire un dump de mémoire brute derrière un pointeur en cours de débogage. Mais ce n’est pas tout : ouvrez une vue de la mémoire pendant le débogage et suivez les modifications apportées à la mémoire pendant l’exécution étape par étape :
Cette fonctionnalité n’est pas encore finalisée. Par exemple, l’une des prochaines mises à jour vous permettra de faire un dump de l’adresse de mémoire arbitraire en mode Debug.
Vue Disassembly
La vue Disassembly a été améliorée, afin d’y afficher les informations catégorisées par fonction. Cela fonctionne pour LLDB, de sorte que LLDB et GDB sont tous les deux couverts.
Utilisez Force Step Into (Maj+Alt+F7 sous Win/Linux, ⌥⇧F7 sous macOS) sur une fonction sans code source pour ouvrir cette vue :
Variables silencieuses
Le calcul des variables peut prendre un temps considérable et cela risque d’avoir un impact déterminant sur les performances lors de l’exécution du code étape par étape. Si vous devez garder un œil sur les calculs de variables, cela peut demander énormément de travail alors que cela n’aura pas d’utilité au final. Dans ce cas, vous pouvez désormais rendre les variables silencieuses avec la commande Mute via un paramètre général de l’EDI. Et lorsque c’est vraiment nécessaire, vous pouvez appliquer la commande Load pour calculer la variable de l’étape active.
Langages injectés
Les litéraux de chaînes avec des éléments de code peuvent être traités comme des éléments de code réels. Par conséquent, le surlignage du code, ainsi que les intentions et les actions propres au langage, peuvent leur être appliqués. Cela s’avère particulièrement utile pour les chaînes SQL ou HTML, ou les expressions régulières.
Pour injecter temporairement un langage, appuyez sur Alt+Entrée et appliquez l’intention « Inject language or reference », sélectionnez le langage correspondant et c’est terminé ! Désormais, vous pouvez modifier les fragments de code dans la section dédiée de l’éditeur ou appliquer une action spécifique. Par exemple, vous pouvez vérifier si une chaîne correspond à l’expression régulière directement dans l’EDI :
N’est-ce pas pratique ?
Égayez votre EDI avec des thèmes de couleur personnalisés !
Si les thèmes par défaut blanc et Darcula ne vous suffisent pas, vous avez la possibilité de créer un thème personnalisé ! Toutes les couleurs de tous les éléments de votre EDI, des icônes et boutons radio jusqu’aux flèches, sont désormais totalement configurables. Adaptez-les en fonction de vos préférences, puis enregistrez-les sous forme de nouveau plugin de thème. Ce tutoriel explique comment procéder.
Mise à jour du plugin Rust
Le plugin IntelliJ Rust assure la prise en charge de Rust, ainsi que le système de build Cargo et le débogueur dans CLion. Cette version lui apporte une mise à jour importante :
- Les Profilers sont désormais pris en charge pour Rust : DTrace sous macOS et Perf sous Linux.
- Les éléments hors de portée sont suggérés lors de la saisie automatique et déclenchent l’importation automatique lorsqu’ils sont utilisés.
- L’injection du langage Rust dans des extraits de code, dans doc comments est maintenant possible.
- Différentes améliorations ont été apportées à l’annotateur
Cargo checket aux formateurs LLDB et GDB.
Restez à l’écoute, car nous publierons bientôt un article de blog détaillé sur les modifications récentes (vous pouvez également vous abonner à notre actualité Rust dans le blog).
Autres améliorations
Les autres améliorations incluent la nouvelle fenêtre contextuelle Recent Locations qui donne une vue d’ensemble de tous les emplacements que vous avez visités par ordre chronologique, des versions mises à jour des packages intégrés de CMake (3.13) et LLDB (7.0.1), ainsi que la version la plus récente de Cygwin (3.0).
D’autre part, le processus de création des builds de plugin de CLion a été simplifié en publiant CLion en tant que dépendance Maven devant être utilisée par gradle-intellij-plugin (depuis la version 0.4.2).
C’est tout ! Nous vous invitons à tester toute ces nouvelles améliorations et à nous dire ce que vous en pensez.
Auteur de l’article original en anglais : Anastasia Kazakova
Subscribe to JetBrains Blog updates
