CLion 2020.2: prise en charge du modèle de conception Makefile, plus de C ++ 20 et plus

Bonjour, Habr!



Notre équipe a connu un été très chargé dont nous sommes pressés de partager aujourd'hui les résultats. Alors, bienvenue à la nouvelle version de CLion 2020.2!







En bref sur ce qui est inclus dans la nouvelle version :

• Prise en charge du modèle de conception Makefile.
• Dernières mises à jour de CMake.
• C++20: explicit(bool), (designated initializers), for .
• : (dangling pointers), , , , .
• -: doctest, Catch2 Google Test. .
• PlatformIO .
• .
• .
• .

Makefile

Après avoir célébré le cinquième anniversaire de CLion ce printemps , nous nous sommes immédiatement impliqués dans l'achèvement actif de la fonctionnalité la plus attendue de l'EDI - le soutien aux projets basés sur le Makefile. Avant cela, nous n'avions qu'un prototype grossier, que nous avons donné à nos utilisateurs les plus audacieux pour qu'ils les essayent en privé. Grâce à eux, nous avons pu tester le prototype sur une large sélection de projets Makefile, résoudre de nombreux problèmes et comprendre les limitations actuelles (espérons-le temporaires) de notre solution. Notre objectif est de permettre aux utilisateurs de travailler avec un projet Makefile dans CLion avec toutes les fonctionnalités intelligentes de l'IDE telles que la navigation, les refactorisations, l'analyse de code statique, etc.



L'approche actuelle en bref ressemble à ceci: CLion exécute une commande makesur votre projet avec une option supplémentaire--just-printpour gagner du temps lors de l'assemblage proprement dit. Si CLion parvient à analyser la sortie de la commande, le projet s'ouvre et tout fonctionne!



Faisons une réserve tout de suite que le travail sur la prise en charge de Makefile dans CLion est loin d'être terminé - il existe encore de nombreuses limitations et imperfections connues. Le plus notable:

• Les projets utilisant libtool ( CPP-19549 ), distcc et ccache ( CPP-19305 ) et d'autres wrappers qui "cachent" les indicateurs de compilation de la sortie ou interfèrent avec la sortie de commande ne sont pas pris en charge make.
• CLion n'est pas encore capable de gérer la sortie Makes non-GNU (par exemple NMake, BSD) ( CPP-18723 ).
• Les projets qui désactivent la liste des noms de répertoires pendant le processus de génération ne sont pas pris en charge, de sorte que CLion ne peut pas déterminer quels fichiers sont spécifiques à quelles commandes de génération.

Mais même la solution actuelle vous permet déjà d'ouvrir le noyau Linux ou le code du serveur de base de données PostgreSQL dans CLion. Si vous êtes intéressé, la liste actuelle des projets où notre prototype fonctionne (ainsi que certains projets où cela ne fonctionne pas, avec les problèmes indiqués) peut être trouvée sur cette page .



C'est très simple d'essayer votre projet:

1. Préparez un projet afin d'obtenir un Makefile pour lui (par exemple, dans de nombreux cas, vous devez le démarrer ./configure, car CLion lui-même ne sait pas encore comment faire cela).
2. Ouvrez un projet avec Fichier | Ouvrez et spécifiez le répertoire qui contient le Makefile du projet principal ou directement ce fichier lui-même. Confirmez que vous souhaitez ouvrir en tant que projet.
3. CLion , Clean. , make , .
4. , , ! Build.

La sortie peut contenir des avertissements, mais si le téléchargement s'est terminé avec succès dans l'ensemble (il devrait y avoir une marque verte à côté de la toute première tâche), alors vous pouvez travailler avec le projet dans CLion.



Les paramètres d'argument de la commande de démarrage, la chaîne d'outils utilisée pour démarrer et d'autres options se trouvent dans Paramètres / Préférences | Construction, exécution, déploiement | Makefile:







pour exécuter et déboguer des applications Makefile, vous devrez créer des configurations d'application Makefile supplémentaires. Dans ce cas, la cible peut être sélectionnée dans la liste déroulante - CLion vous indiquera les options disponibles:







Dans notre blog en anglais, vous pouvez trouver plus d'informations sur l'utilisation de projets Makefile dans CLion. Nous vous recommandons également de regarder une courte démo (en anglais):

Dernières mises à jour dans CMake

Comme le montrent les statistiques , les trois modèles de conception les plus populaires actuellement parmi les développeurs C ++ sont CMake, msbuild et Makefile. Et c'est CMake qui mène ce classement depuis trois ans et continue de croître. Par conséquent, nous mettons constamment à jour la version de CMake qui est interdite dans CLion et travaillons sur le support des dernières innovations de CMake lui-même. Cette fois, nous avons mis à jour la version 3.17 et ajouté en conséquence la prise en charge de deux nouvelles fonctionnalités utiles de CMake:

• Ninja Multi-Config ( Debug Release) Ninja ( -G "Ninja Multi-Config"). CLion , CMake . UI, .
• Les en-têtes précompilés CMake méritent plus d'attention. En général, l'idée des fichiers d'en-tête précompilés (PCH) n'est pas nouvelle et est supportée par les compilateurs depuis longtemps. CLion travaille également avec PCH depuis un certain temps. Vous n'avez plus besoin de vous souvenir des indicateurs de compilateur pour PCH et de les transmettre à CMake à chaque compilateur spécifique à votre manière, mais ajoutez simplement des fichiers d'en-tête aux variables cibles PCH via la commande target_precompile_headers. CLion 2020.2 est désormais capable de travailler avec ceci:
  
  
  
  

Il convient également de noter la possibilité d'ouvrir un projet CMake dans CLion à partir du répertoire avec le résultat de la génération CMake, maintenant non seulement pour le générateur Makefile, mais pour tout autre! Gagnez du temps - ouvrez des projets déjà créés dans CLion sans redémarrer la commande CMake sur le projet.

C ++ 20

Saviez-vous que, selon nos données , cette année déjà 12% des développeurs C ++ utilisent le standard C ++ 20?! Par conséquent, nous travaillons bien entendu activement à la prise en charge des nouvelles fonctionnalités de CLion. Mais rappelons d'abord ce que nous avons avec les moteurs de langage dans CLion.



Donc, pour le moment, il y en a deux - un intégré basé sur Java / Kotlin et un assez nouveau basé sur Clangd, respectivement en C ++ (nous utilisons CLion pour son développement). Tous les efforts sont maintenant mis dans un moteur basé sur Clangd. Cela semble être une bonne perspective, bien que des actions sur l'ensemble du projet (comme les refactorisations) ne puissent pas encore être effectuées sur celui-ci - ici même un moteur Java imparfait et parfois lent l'emporte en raison de toutes sortes d'optimisations spécifiques et de résolutions différées, et, bien sûr, en raison de la présence d'un cache symboles nécessaires pour les refactorisations.



Mais Clangd a un très gros plus - toute la communauté y travaille pour prendre en charge les dernières normes C ++ à Clang, car le projet est ouvert. Bien entendu, cela ne veut pas dire que nous n’avons rien à faire du tout - ce soutien doit encore être adapté aux besoins de CLion. Mais c'est déjà plus facile que d'écrire la prise en charge des fonctionnalités C ++ à partir de zéro! Et sur la base de la prise en charge de Clang, vous pouvez écrire votre propre analyse spécifique ou effectuer des fonctionnalités spéciales (par exemple, nous avons effectué l' auto - complétion pour Concepts il y a quelques versions).



Nous nous sommes assurés que la dernière mise à jour du moteur Clangd, fournie avec LLVM, se comporte de manière plus stable dans le code C ++ 20, et en général, selon nos statistiques intégrées, le moteur Clangd est devenu plus stable. Par conséquent, la possibilité de désactiver complètement le moteur Clangd a été supprimée des paramètres. Mais ajouté à Paramètres / Préférences | Langues et cadres | C / C ++ | Clangd informations sur la révision avec laquelle notre moteur est construit. Vous savez maintenant à quoi vous attendre en termes de prise en charge du C ++ et d'analyse de Clang-Tidy intégré:







Au fait, notre aide en ligne contient un excellent article avec une analyse comparative des deux moteurs en termes de prise en charge des capacités C ++.



Et maintenant à propos de ce qui a été réellement ajouté à partir du support C ++ 20:

• La complétion de code C ++ 20 mots - clés: char8_t, consteval, et constinit, co_await, co_returnet co_yield.
• Complétion pour les champs de la classe de base dans les initialiseurs désignés:
  
  
  
  
• La construction est explicit(bool)maintenant correctement mise en évidence, les conseils de nom, la navigation et les refactorisations y fonctionnent:
  
  
  
  
• Pour les boucles forbasées sur des plages avec des initialiseurs, la refactorisation Rename pour les variables de boucle fonctionnait.

Analyseur de code statique

Dans la dernière version, nous avons transféré notre analyse la plus «lourde» - l'analyse des flux de données - vers un moteur basé sur Clangd. C'est principalement pour améliorer les performances. Mais, comme cela arrive souvent, lors de la refactorisation, de nombreux problèmes et inexactitudes ont été découverts. Ainsi, dans la version 2020.2, nous avons continué à améliorer cette analyse et à y corriger des bogues:

• , , .
• DFA Simplify code Loop condition is never updated. , :
  
  
  
  
  
  
  
  , :
  
  
  
  
  
  
  
  - , . , Clang-Tidy (clang-tidy:bugprone-infinite-loop), - . CLion :
  
  
  
  
• CLion (dangling pointers)! (, ), :
  
  
  
  
• , Concepts C++20, - auto, :
  
  
  
  

Dans cette version, l'Inspection Hector préférée de tous (dont certains de nos utilisateurs ont même tenté en vain de se moquer ) s'est transformée en un nouveau widget d'inspection situé dans le coin supérieur droit de la zone de l'éditeur. Maintenant, c'est là que se trouvent les options de réglage du niveau de rétroéclairage (de l'affichage de tous les problèmes à la désactivation complète de l'analyseur de code), et lorsque vous cliquez sur, la fenêtre des résultats de l'analyse statique de ce fichier s'ouvre:

Test unitaire

La recherche déjà mentionnée ici à plusieurs reprises montre que 34% des développeurs C ++ n'écrivent aucun test unitaire . Je voudrais croire qu'en retour, ils effectuent des tests d'une autre manière. Une partie du problème est que C ++ n'a pas de modèle de conception standard ou de gestionnaire de dépendances standard, ce qui signifie que l'ajout d'un cadre de test unitaire à votre projet n'est pas facile. Mais maintenant, les frameworks dits d'en-tête seulement deviennent particulièrement populaires, qui sont faciles à connecter à votre projet - ajoutez un fichier d'en-tête et écrivez vous-même des tests. Pour notre part, dans l'EDI, nous essayons de prendre en charge autant d'options que possible. Dans cette version, doctest a été ajouté à l'ensemble de Google Test, Catch, Boost.Test. Au fait, nous avons publié un article sur un blog invité il y a quelque tempsde son auteur, où Viktor a parlé des avantages de ce cadre.



La prise en charge de CLion comprend les éléments habituels:

• Détection de test automatique.
• Création automatique de configurations pour l'exécution et le débogage des tests.
• Sortie des résultats du test dans une fenêtre intégrée spéciale avec diverses options de filtrage et de classement, ainsi qu'avec une transition vers le code source du test en un clic.
• Icônes dans l'éditeur, dans le volet gauche, pour exécuter des tests et identifier l'état de la dernière exécution de tests.

La prise en charge de Google Test et Catch2 a également été mise à jour:

• La prise en charge des tests de modèle a été ajoutée pour Catch2.
• Et pour Google Test, prise en charge d'une macro GTEST_SKIP(), ce qui peut être très utile si vous voulez pouvoir sauter certains tests, par exemple, dans des environnements spécifiques.

Une petite vidéo de présentation sur les améliorations de la prise en charge des tests unitaires de notre avocat (en passant, l'auteur du framework Catch / Catch2):





Attention à vos questions sur CTest: c'est un peu plus difficile à faire, car ce n'est pas un framework «régulier», mais un certain niveau d'abstraction pour exécuter quoi que ce soit comme un test. Mais nous prévoyons une intégration dès 2020.3!

Et

Le plus intéressant, peut-être, discuté, maintenant brièvement sur le reste. J'aurais dû commencer par cela, mais CLion 2020.2 inclut de nombreuses améliorations petites mais importantes des performances de l'éditeur et des corrections de blocage de l'éditeur. Une telle amélioration, par exemple, est l'insertion d'une barre oblique inverse lorsqu'elle est enfoncée Enter dans une définition de macro . Il semblerait que cela contribue à la productivité de l'éditeur? Le fait est que très probablement la nouvelle ligne fait partie de la définition de la macro actuelle, et l'insertion d'une barre oblique inverse vous permet d'éviter une réanalyse inutile d'un tas de code, et donc les freins de l'éditeur.



Outre:

• PlatformIO — , platformio.ini CMake .
• , IntelliJ . : GitHub Pull Requests Git WSL2 ( WSL2, CLion Git ).
• En termes de débogueurs en 2020.2, nous avons réussi à faire moins que prévu. Fondamentalement, toutes les grandes tâches ont été repoussées à 2020.3 (débogage en tant que root, débogage des vidages de mémoire). Mais dans cette version, nous avons mis à niveau la version interdite de GDB vers 9.2 et également mis à jour les jolies imprimantes GDB STL. De nombreuses améliorations, à la fois fonctionnelles, de performances et de stabilité, ont été apportées à notre débogueur basé sur LLDB pour la chaîne d'outils Microsoft Visual C ++.

C'est tout pour aujourd'hui. Avez-vous lu jusqu'au bout? Merci beaucoup pour votre attention! Essayez-le , écrivez des questions, des suggestions, des exclamations dans les commentaires - nous sommes toujours heureux de les lire et d'y répondre!



L'équipe CLion

La volonté de se développer