Sortie de CLion 2019.2: support de développement intégré, débogueur pour MSVC, recherche de fichiers d'en-tête inutilisés

Bonjour, Habr!

L'été hors de la fenêtre s'annonce presque imperceptiblement, car nous avons consacré tous ces mois à travailler sur la nouvelle version 2019.2 de notre environnement de développement multiplateforme pour C ++ - CLion. Nous avons réussi à faire beaucoup de choses: mener un Hackathon interne, essayer de nouvelles idées et apporter un certain nombre de corrections et de nouvelles fonctionnalités à une version immédiate. Mais tout d'abord.



En bref, dans cette version, nous:

• Nous avons continué d'affiner la prise en charge du développement de systèmes embarqués: de nouvelles capacités de débogage et de visualisation des périphériques sont apparues.
• Le débogueur expérimental pour MSVC a été amené à une qualité acceptable.
• Nous avons complètement réécrit la vérification du code sur Inutilisés inclut sur clangd, en ajoutant la possibilité de configurer différentes stratégies.
• Implémentation de conseils pour les arguments d'appel de fonction et les lambdas pour améliorer la lisibilité du code.
• Nous avons mené un Hackathon intra-équipe pour améliorer la productivité, trouvé un tas de nouvelles approches et réussi à mettre en œuvre plusieurs améliorations.
• Nous avons implémenté la coloration syntaxique pour plus de 20 langues, construit dans un plugin Shell Script et mis à jour le plugin Rust.

Ce n'est bien sûr pas tout . 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.

Nouvelles fonctionnalités pour le développement embarqué

Dans la version précédente, pour une raison quelconque, beaucoup pensaient que nous nous concentrions uniquement sur les cartes STM32. Bien sûr, c'est l'un des marchés les plus intéressants et les plus étendus de nombreuses études (y compris notre marché intérieur), mais nous essayons maintenant de résoudre des problèmes plus généraux. Par exemple, nous avons étendu les capacités de débogage sur différentes cartes de CLion.

Auparavant, la seule option était la configuration du débogueur OpenOCD - OpenOCD Download & Run. Maintenant, un autre est apparu - Embedded GDB Server. En fait, si la carte prend en charge le débogage via un serveur GDB compatible, vous pouvez le déboguer via CLion. La configuration couvre des cas tels que OpenOCD, les serveurs GDB ST-Link, le serveur GDB Segger J-Link, QEMU et plus encore.



Il suffit de créer et de configurer la configuration appropriée - spécifiez le chemin d'accès au serveur GDB, les arguments que vous lui passez, peut-être des paramètres plus avancés. Maintenant, exécutez le débogage dans cette configuration et vous pouvez déboguer sur la carte directement depuis CLion!

Il existe une limitation importante qui affecte désormais les deux configurations de débogage des systèmes embarqués - les deux ne fonctionnent actuellement qu'avec des projets sur CMake. À l'avenir, nous prévoyons d'ajouter la possibilité de les exécuter pour des modèles de conception personnalisés ( CPP-16079 ).

Pour les deux configurations de débogage existantes des systèmes embarqués (serveur GDB intégré et OpenOCD Download & Run), la nouvelle version a désormais la possibilité d'afficher les périphériques pendant le débogage. En général, les périphériques sont spécifiés pour les appareils de la famille ARM au format .svd . Ces spécifications peuvent maintenant être chargées dans CLion et afficher les périphériques sélectionnés directement dans la fenêtre du débogueur:



Tous les périphériques sont toujours disponibles en mode lecture seule, tandis qu'il existe une recherche par nom, la possibilité d'afficher les valeurs dans différents modes (hexadécimal, décimal, octal et binaire). Vous pouvez en lire un peu plus sur notre blog (en anglais).

Débogueur expérimental pour MSVC

Vous avez bien lu - dans la version 2019.2, CLion a introduit un débogueur expérimental pour le code compilé à l'aide de MSVC! Maintenant, comprenons un peu plus en détail et dans l'ordre.

Pendant longtemps dans CLion, vous pouvez utiliser non seulement la chaîne d'outils MinGW et Cygwin, mais également Visual Studio lors du développement sur la plate-forme Windows. Vous spécifiez le chemin vers le VS installé dans CLion, et à partir de là, nous prenons le compilateur MSVC et les scripts pour configurer l'environnement. Mais il y a eu des problèmes avec le débogueur pendant longtemps. Le fait est que le débogueur que Visual Studio utilise lui-même est propriétaire. Autrement dit, nulle part, sauf les outils Microsoft, il ne peut être utilisé sous licence. Il existe une technologie alternative - dbgeng.dll , sur laquelle les débogueurs CDB et WinGDB sont implémentés. La première chose que nous avons testée était elle. Mais il nous a semblé que gérer le nombre de plantages critiques et les mauvaises performances sur les binaires avec un grand nombre de fichiers PDB n'est pas très prometteur (bien que nous ayons essayé au début). Et puis il s'est avéré qu'il existe une troisième option - pour implémenter un débogueur au-dessus de LLDB. Il y a déjà eu des réalisations et nous n'avons eu qu'à poursuivre ce travail. Ce que nous avons fait! Soit dit en passant, nous avons mis toutes nos modifications (à l'exception de la prise en charge des visualiseurs de données natifs pour l'instant) dans l'assistant LLVM.

Comment activer? Comme je l'ai déjà écrit, l'opportunité est encore expérimentale. Il est trop tôt pour appeler un débogueur à part entière, il présente de nombreuses limitations et lacunes, et les performances nécessitent des optimisations importantes. Cette fonctionnalité expérimentale est activée dans la boîte de dialogue Maintenance ( Shift+Ctrl+Alt+/ sous Linux / Windows, ⌥⇧⌘/ sous macOS) | Caractéristiques expérimentales | cidr.debugger.lldb.windows . Maintenant, un nouveau débogueur est disponible pour la chaîne d'outils Visual Studio:



Le débogueur prend en charge initialement les visualiseurs natifs, tous deux fournis avec le studio, et ceux personnalisés personnalisés trouvés dans le projet. Pour l'instant, la fonctionnalité nécessite une inclusion explicite dans les paramètres: Paramètres | Construction, exécution, déploiement | Vues des données du débogueur | Activez les rendus NatVis pour LLDB. Dans l'une des premières mises à jour, nous prévoyons de résoudre plusieurs problèmes critiques avec les visualiseurs, puis de les activer par défaut.



Si vous prévoyez d'essayer un nouveau débogueur expérimental, nous vous recommandons de vous familiariser avec la liste des limitations et problèmes connus sur notre blog .

Autres améliorations du débogueur

En plus du nouveau débogueur expérimental, nous avons apporté un certain nombre d'autres améliorations:

• Dans la console GDB / LLDB intégrée, dans la fenêtre du débogueur dans CLion, la saisie semi- automatique des commandes du débogueur fonctionne désormais (utilisez Tab ou Ctrl+Space ).
• Les points d'arrêt de chaîne sont désormais validés à la volée , et leur statut est mis à jour et affiché à l'utilisateur sous la forme d'une icône correspondante. Le type le plus intéressant est Invalid , qui a été ajouté pour identifier les points d'arrêt qui ne sont pas disponibles dans le code exécutable actuel ou pour lesquels il n'y a pas de symboles de débogage (dans ce cas, après les avoir chargés, l'état du point d'arrêt sera automatiquement mis à jour):
  
• Lors de la visualisation de la mémoire dans le débogueur (Memory View) dans la nouvelle version, il est devenu possible de basculer vers une adresse arbitraire (par adresse numérique ou nom / adresse de variable), ainsi que de présenter la mémoire au format ASCII:
  

Améliorations de l'éditeur de code

Il y a plusieurs grandes améliorations dans ce domaine. Tout d'abord, nous avons complètement réécrit la vérification du code inclus non utilisé et l'avons activé par défaut. Auparavant, il était également présent, mais il donnait un grand nombre de faux positifs, nous l'avons donc désactivé par défaut. Pourquoi ça va mieux? Nous avons complètement réécrit la vérification sur la base du deuxième outil supplémentaire pour analyser le code, qui, à son tour, est basé sur Clangd. Il s'agit donc d'une limitation claire - la nouvelle version ne fonctionnera que si Clangd n'est pas désactivé pour vous (par défaut, il est activé). Mais maintenant, en vérifiant les inclus inutilisés, plusieurs stratégies sont apparues, parmi lesquelles vous pouvez choisir:

Par défaut, Détecter non directement utilisé est utilisé , ce qui est essentiellement le plus proche du principe bien connu d' inclure ce que vous utilisez , c'est-à-dire que si les déclarations du fichier d'en-tête ne sont pas utilisées directement dans ce fichier, un tel fichier d'en-tête est marqué comme inutilisé.

Dans les paramètres d'inspection (Paramètres / Préférences | Éditeur | Inspections | C / C ++ | Code inutilisé | Directive d'inclusion inutilisée), vous pouvez également choisir d'exécuter la vérification dans les fichiers d'en-tête eux-mêmes. Certes, cela ne fonctionnera que dans les fichiers d'en-tête où #pragma ou des gardes d'en-tête sont présents. Il est également important de savoir que si des erreurs de compilation sont présentes dans le fichier source, la vérification n'affichera pas les fichiers inutilisés.

Depuis la dernière version, CLion prend en charge ClangFormat en tant qu'outil de formatage de code alternatif, en plus de l'outil intégré. Dans cette version, nous avons ajouté un schéma JSON intégré pour les fichiers de configuration au format .clang. Et grâce à cela, nous avons pu ajouter plusieurs fonctionnalités qui pourraient être utiles à ceux qui modifieront les fichiers au format .clang dans CLion:

• La saisie semi-automatique est apparue pour les options et leurs valeurs.
• Dans la fenêtre de saisie semi-automatique des options, il y a maintenant une description des options.
• La fenêtre de documentation de la documentation rapide ( Ctrl+Q sous Windows / Linux, F1 sous macOS) affiche la documentation des options et leur signification, avec des exemples.
• La validation des options pour les valeurs valides est ajoutée.

Conseils pour les arguments

Que se passe-t-il si la fonction est écrite (peut-être pas par vous) de sorte que 3 entiers lui soient passés comme arguments? Comment comprendre par un appel de fonction ce que signifient les valeurs transférées? Bien sûr, vous pouvez voir la signature de la fonction dans la fenêtre de documentation, aller à la définition de la fonction ou appeler les informations de paramètre (Parameter Info). Et si vous ne faites pas ces actions explicites?

Dans la version CLion 2019.2, des info-bulles pour les arguments sont apparues - lors de l'appel d'une fonction, lambda, constructeur, liste d'initialisation ou lors de l'utilisation d'une macro, CLion affiche les noms des paramètres avant le passage des arguments:
Des conseils sont affichés dans les cas où il est vraiment difficile de comprendre quelles valeurs sont passées à quels paramètres, à savoir si des littéraux ou des expressions avec plus d'un opérande sont utilisés comme arguments. Plus de détails sur le blog .

Performances

Bien sûr, nous sommes souvent interrogés sur les améliorations de performances. Je le répète, pour nous, c'est la tâche la plus prioritaire, mais il s'avère qu'il n'y a pas beaucoup de changements ponctuels, et les changements globaux prennent plus de temps que 1-2 cycles de publication. Maintenant, il y a plusieurs grands changements dans le travail. Fondamentalement, ils sont liés à la façon dont l'analyseur dans CLion interagit avec l'architecture de la plate-forme (qui ne calcule pas toujours qu'un long code de résolution est caché derrière une action simple, dans le cas de C ++).

Cet été, l'équipe et moi avons décidé d'organiser un Hackathon interne pour identifier les points les plus vulnérables de l'architecture et de la plateforme CLion, essayer de nouvelles idées audacieuses et tester certaines vieilles hypothèses. Nous avons aimé les résultats. Si possible, nous prévoyons d'apporter de nouvelles idées à la sortie d'ici 2019.3.

Mais la version 2019.2 n'est pas restée sans amélioration des performances:

• Nous nous sommes débarrassés de nombreux ralentissements et blocages lors de la refactorisation de Renommer sur place.
• Amélioration des performances de complétion automatique pour les expressions qualifiées.
• Dans le cas du travail à distance, nous avons réduit le nombre d'opérations d'E / S, ce qui a considérablement accéléré la collecte d'informations sur le compilateur et, par conséquent, la vitesse de téléchargement du projet CMake.
• Et d'autres améliorations.

Pas seulement C ++

À partir de la plateforme IntelliJ dans CLion 2019.2, de nombreuses améliorations ont été apportées pour fonctionner avec d'autres langues.

La coloration syntaxique de plus de 20 langues est désormais fournie par les grammaires TextMate (une liste complète des langues se trouve dans Paramètres / Préférences | Éditeur | Ensembles TextMate). Bien sûr, si pour ce langage il existe un support étendu en CLion (Python, JavaScript, HTML, Objective-C, SQL), alors il sera utilisé, mais pour des langages tels que Ruby, la mise en évidence la plus simple peut être utile:



Souvent, dans les projets C ++, il existe une variété de scripts . Le plugin Shell Script est maintenant intégré à CLion. Il fournit non seulement la mise en évidence du code, mais également la saisie semi-automatique et le changement de nom du texte:



Le plugin Rust a reçu de nombreuses mises à jour utiles. D'un nouvel outil d'expansion de macros expérimental (Paramètres / Préférences | Langues et cadres | Rust | Développez les macros déclaratives) aux fragments de code en double , diverses nouvelles corrections rapides et l'auto-complétion dans le débogueur dans Évaluer les expressions . Soit dit en passant, c'est dans CLion que la plus grande utilisation de ce plugin est maintenant parmi tous les IDE de JetBrains!

Démo

Vidéo traditionnelle sur les nouvelles fonctionnalités de CLion 2019.2 (en anglais):


C'est tout pour une fois. Merci d'avoir lu jusqu'au bout! Des questions, des souhaits, des rapports de bugs et seulement des pensées exprimées dans les commentaires! Comme toujours, nous serons heureux de répondre.

Votre équipe JetBrains CLion
La volonté de se développer