Hallo habr Viele bereiten sich schon auf die Neujahrsferien vor, kaufen Geschenke, jemand plant eine Reise für die langen Neujahrsferien. Und bei JetBrains ist es immer noch eine heiße Zeit für uns, Produktversionen herauszubringen. Heute habe ich es eilig, Ihnen die Neuigkeiten über die kürzlich veröffentlichte Veröffentlichung unserer plattformübergreifenden Entwicklungsumgebung für C und C ++ - CLion 2019.3 mitzuteilen.
Das Hauptziel dieser Veröffentlichung war, wie erbärmlich es auch klingen mag, Qualität. Wir haben uns entschlossen, uns auf die Probleme zu konzentrieren, die unsere Benutzer seit langem beschäftigen - zum einen auf die Produktivität und Reaktionsfähigkeit des Editors und zum anderen auf Fehler, Mängel und sehr beliebte, aber fehlende Funktionen.
Zunächst kurz das Wichtigste in dieser Version:
- Verbesserungen in der Geschwindigkeit und Reaktionsgeschwindigkeit des Editors, hauptsächlich die automatische Vervollständigung, die in unserer auf Clangd basierenden Engine implementiert ist.
- Ninja-Generator in CMake, Standardeinstellungen für CMake und andere Verbesserungen des Designmodells.
- Aktualisierungen in Verbindung mit Debuggern.
- Neue Aktion zum Umschalten zwischen Header- und Sour-Dateien.
- Genauere Code-Analyse: Neue Prüfung für virtuelle Funktionen sowie Rechtschreibprüfung in CMake- und Doxygen-Kommentaren.
- Unterstützung für Konzepte aus dem C ++ 20-Standard.
- Kennzahlen zur Codeabdeckung.
- WSL2, die Formatierungs- und Namenskonventionen von Microsoft, Aktualisierungen der VCS-Unterstützung und mehr.
Wir werden im Folgenden näher darauf eingehen. Wenn Sie es jetzt ausprobieren möchten, laden Sie das Build von
unserer Website herunter . Wie üblich ist eine kostenlose Testversion für 30 Tage verfügbar.
Editorleistung
Gemessen an den Statistiken, denen viele unserer Benutzer zustimmen, ist die in CLion am häufigsten verwendete Aktion die
automatische Vervollständigung . Wir haben beschlossen, uns in dieser Veröffentlichung auf ihn zu konzentrieren, um die Reaktionsfähigkeit zu verbessern. Zu diesem Zweck haben wir den in der IDE bereits vorhandenen Autocomplete-Anbietern einen weiteren auf Clangd basierenden hinzugefügt. Unter dem Strich arbeiten alle Lieferanten parallel. Sobald die ersten Ergebnisse vorliegen, zeigt CLion eine Dropdown-Liste mit Optionen an und lädt bei Bedarf weitere Optionen.
Natürlich wollten wir verstehen, ob ein solcher hybrider Ansatz Vorteile bietet. Die Messungen zeigten, dass sich bei einfachen Projekten die Geschwindigkeit des CLion-Anbieters und des Clangd-basierten Anbieters nicht wesentlich unterscheidet. Bei komplexen Projekten wie LLVM, Qt, Boost, Eigen erscheinen die ersten hundert Ergebnisse von Clangd jedoch viel schneller. Überzeugen Sie sich selbst:
Weitere
Informationen zu Messungen finden Sie in einem separaten
Artikel im englischsprachigen CLion-Blog.
Unter anderen signifikanten Verbesserungen ist die Plattformbeschleunigung der IDE-Startzeit zu erwähnen. Dies wurde erreicht, indem viele Prozesse zu Beginn parallelisiert, die zu Beginn geladenen Klassen neu organisiert und das Laden von Schriftarten unter macOS optimiert wurden. Die zu beschleunigenden Zahlen hängen von den Einstellungen der Umgebung, des Fahrzeugs, der Plattform und anderen Faktoren ab.
In CLion gibt es zu unserem großen Bedauern immer noch Probleme mit der Benutzeroberfläche. Wir versuchen, sie nach dem ursprünglichen Problem zu gruppieren und ein Problem nach dem anderen zu beheben. Daher haben wir in dieser Version das Einfrieren bei geöffneter Usages View, beim Wechsel zu einer Deklaration, beim Umbenennen der Direktive
#include , bei der Verwendung von Semmelbröseln und Safe Delete sowie in anderen Fällen behoben. Benutzeroberflächensperrungen bleiben das dringlichste Problem für uns, daher werden wir diese Arbeit in zukünftigen Versionen definitiv fortsetzen.
Und schließlich
Umbenennen der Umgestaltung der Beschleunigung . Dieses Refactoring kann nicht nur die Verwendung des Namens im Code umbenennen, sondern auch Zeichenfolgenliterale und Kommentare. Dies ist jedoch nicht immer erforderlich, und die Suche nach dem Namen wurde durchgeführt, bevor der IDE-Benutzer angab, welche bestimmten Verwendungen umbenannt werden würden. Dies führte zu langen Verzögerungen bei der Suche nach einem beliebten Namen. Jetzt können Sie zuerst eine Suche nur nach Code auswählen und dann die Suche selbst starten. Gehen Sie dazu zu Einstellungen / Einstellungen | Herausgeber | Allgemein | Refactorings müssen deaktiviert sein "In-Place-Modus aktivieren". In diesem Fall öffnet CLion beim Aufrufen von Refactoring (standardmäßig Umschalt + F6 unter Windows / Linux, ⇧F6 unter macOS) sofort das Dialogfeld "Umbenennen", in dem Sie die Suchparameter angeben können:
Verbesserungen am CMake-Designmodell
Hier müssen viele von Ihnen auf die Ankündigung der Unterstützung für Makefiles gewartet haben. Bisher ist jedoch nur ein
halbautomatischer Ansatz für die Integration über die Zusammenstellungsdatenbank verfügbar. Weitere native Unterstützung ist noch in der Entwicklung, aber in diesem Release-Zyklus haben wir große Fortschritte erzielt und wir haben jede Chance, Ende März 2020 neue Unterstützung für das nächste Release 2020.1 zu zeigen.
Wir haben jedoch die lang ersehnte Gelegenheit genutzt, CMake zu unterstützen - die Möglichkeit, jeden CMake-Generator anzugeben, einschließlich des
Ninja- Generators, der von den Benutzern so sehr erwartet wird! Zuvor haben wir Makefiles und ähnliche Generatoren verwendet, da wir die resultierenden Dateien analysiert haben (genauer gesagt:
-G "CodeBlocks - Unix Makefiles" und unter Windows
-G "CodeBlocks - MinGW Makefiles" und
-G "CodeBlocks - NMake Makefiles"). ) Jetzt können Sie in CLion einen beliebigen Generator im CMake-Profil angeben:
Dies ist nur möglich, wenn CMake Version 3.15 oder höher verwendet wird, da es über die CMake-Datei-API implementiert wird und für WSL / WSL2 auf allen Plattformen remote funktioniert.
Ich stelle fest, dass solche Generatoren wie Xcode und Visual Studio Mehrfachgeneratoren sind, das heißt, sie generieren Dateien für alle Arten von Assemblys (Debug, Release usw.), aber CLion verwendet nur den in angegebenen Assembly-Typ CMake-Profil.
In dieser Version wurden auch die
Standardeinstellungen für CMake eingeführt. Dies bedeutet, dass Sie für alle neuen Projekte in CLion dieselben vordefinierten Einstellungen verwenden können, z. B. den CMake-Generator oder das Verzeichnis zum Generieren von CMake. Einstellungen können unter Datei | festgelegt werden Andere Einstellungen | Einstellungen für neue Projekte ...
Unter den wichtigen Verbesserungen des CMake-Projektmodells ist nach wie vor hervorzuheben, dass gültige Konfigurationen erneut geladen werden können, auch wenn andere ungültige Konfigurationen im Projekt vorhanden sind. Dies kann hilfreich sein, wenn Sie mehrere Remote-Konfigurationen konfiguriert haben, die derzeit nicht verfügbar sind, aber mindestens lokale Konfigurationen neu laden möchten.
Update zur Debugger-Integration
In Debuggern haben wir uns entschlossen, die Probleme und Mängel zu beheben, die unsere Benutzer am meisten beschäftigen. Zunächst liest CLion jetzt
.gdbinit / .lldbinit aus dem Projektverzeichnis . Dies ist nützlich, wenn Sie einige Debugger-Einstellungen anpassen oder hübsche Drucker hinzufügen möchten, jedoch nur für ein bestimmtes Projekt. Bisher mussten Sie diese Einstellungen in den Debugger-Konfigurationsdateien im Benutzerverzeichnis angeben. Jetzt können Sie diese projektspezifischen Parameter konfigurieren. Damit dies jedoch funktioniert, müssen Sie dieses Verhalten im Debugger selbst in den Einstellungen auf Benutzerverzeichnisebene aktivieren (lesen Sie, wie dies für
GDB und
LLDB durchgeführt wird ).
Die Integration mit LLDB ist unter Linux und macOS verfügbar. In der neuen Version haben wir die integrierte LLDB auf Version 9.0 aktualisiert und gleichzeitig alle integrierten hübschen Drucker weltweit überprüft. Dadurch hat sich die Leistung von Standardcontainern auf beiden Plattformen deutlich verbessert. Detaillierte Vergleiche finden Sie in unserem
englischsprachigen Blog . Es ist erwähnenswert, dass die
libc ++ - Bibliothek auf der macOS-Plattform viel besser
funktioniert als
libstdcxx . Dies scheint der Popularität dieser Bibliotheken auf dieser Plattform zu entsprechen, aber wenn Sie
libstdcxx unter macOS verwenden, teilen Sie uns diese Fälle bitte in den Kommentaren mit.
CLion verfügt nun über
mehrere Optionen für die Remote-Arbeit mit einem Projekt und das Debuggen. Von der vollständig entfernten Option, wenn sowohl das Assemblieren als auch das Debuggen des Projekts auf einem entfernten Computer erfolgen, zu den Optionen, wenn nur das Projekt remote debuggt wird. Für den zweiten Fall haben wir CLion eine weitere Konfiguration hinzugefügt -
Remote GDB Server . Im Gegensatz zum langjährigen
GDB Remote Debug (wir waren uns einig, dass wir keine Namen hatten) erstellt CLion in der neuen Konfiguration das Projekt selbst (möglicherweise müssen Sie kompilierungsübergreifende Einstellungen konfigurieren), lädt die ausführbare Datei auf den Remote-Computer herunter und führt Ihr Programm unter dem angegebenen gdbserver aus. Die alte Konfiguration eignet sich jetzt besser für komplexe Optionen, wenn sich der Code auf einem Computer befindet, die Assembly auf dem zweiten und das Debuggen auf dem dritten. Oder wenn eine Querkompilierung nicht möglich ist.
Gehen Sie zu den Header- / Quelldateien
Ja, das war es! Wir haben schließlich eine separate Aktion hinzugefügt, um zwischen Header- und Sour-Dateien zu wechseln. Was ist der Hauptunterschied zur alten Plattform? Tatsache ist, dass
Go to Related Symbol als allgemeine Plattformaktion versucht, sehr genau zu sein und eine der korrektesten Optionen auszuwählen. Dies ist sowohl lang als auch im Fall von C ++ nicht immer korrekt. Die neue Aktion
Gehe zu Header / Quelle verhält sich anders:
- Wenn innerhalb von 500 ms keine einzige richtige Option vorhanden ist, wird eine Dropdown-Liste geeigneter Optionen angezeigt, aus der der Benutzer die am besten geeignete auswählen kann.
- Wenn der Benutzer bereits von dieser Datei aus navigiert ist, befindet sich die Datei, zu der er navigiert ist, an der Spitze der Liste.
- Weiter in der Liste befinden sich Dateien aus demselben Verzeichnis mit demselben Namen.
- Und dann werden die Suchergebnisse für übereinstimmende Deklarationen und Definitionen fortgesetzt.
Es lohnt sich, die Suchfunktion zu erwähnen (da unsere Benutzer sie bereits kennengelernt haben) - die Suche wird jetzt für direkt eingeschlossene / einschließende Dateien durchgeführt. Dies ist ein Zeitlimit, das erforderlich ist, um Zeichen mit demselben Namen von verschiedenen Zielen nicht zu verwechseln.
Code-Analyse
In CLion wurde im Code Analyzer eine neue Prüfung angezeigt. Es erfasst Situationen, in denen virtuelle Funktionen von Konstruktoren oder Destruktoren aufgerufen werden. Warum das so ist, wurde bereits
viel diskutiert . Nun warnt CLion vor solchen Fällen:
Die Rechtschreibprüfung ist ein wesentlicher Bestandteil einer integrierten Entwicklungsumgebung. Wir alle machen Rechtschreibfehler und dann fällt es unseren Kollegen schwer, den Code und die Kommentare zu lesen. Daher ist es gut, wenn die IDE solche Fehler hervorhebt. In dieser Version haben wir die Rechtschreibprüfung in CMake-Dateien und Doxygen-Dokumentationskommentare aufgenommen:
Weniger Rechtschreibfehler - mehr lesbarer Code!
Konzepte aus C ++ 20
Unser Team arbeitet intensiv an der Clangd-basierten Sprach-Engine. Und die globale C ++ Community entwickelt Clang aktiv weiter. In dieser Version haben wir uns zusammengeschlossen - wir haben den experimentellen Zweig Clang mit Unterstützung von Konzepten aus C ++ 20, der von Saar Raz entwickelt wurde, in unseren Zweig Clangd übernommen. So haben wir eine Code-Hervorhebung mit Konzepten und grundlegenden Prüfungen des Clang-Analysators in CLion erhalten:
Aber wir haben nicht aufgehört. Und in unserer Clangd-basierten Engine haben wir einige nützliche Fälle implementiert, in denen die automatische Vervollständigung, die Überprüfung der Verwendung eines Konzepts, die
Umbenennung von Konzepten, die Navigation und Suchaktionen
unter "Definition" und "
Suchen nach Verwendungen" durchgeführt wurden .
Automatische Vervollständigung für Vorlagenparameter, die Einschränkungen unterliegen:
std::is_same<Other, T> Vervollständigung für
std::is_same<Other, T> und
same_as<T, U> :
Mehr über unsere gemeinsame Arbeit an Konzepten lesen Sie im
englischsprachigen Blog . Es gibt auch eine Videoaufnahme des Berichts von der CppCon 2019, in der Saar Raz seine Konzeptumsetzung in Clang und unsere gemeinsame Arbeit zur Konzeptunterstützung in CLion vorstellte.
Kennzahlen zur Codeabdeckung
Die Codeabdeckung ist eine Gelegenheit, auf die CLion-Benutzer gewartet haben und nach der sie gefragt haben. In der letzten Version hat das AppCode-Team damit begonnen, in diese Richtung zu arbeiten. In dieser Version haben wir dies für Fälle von plattformübergreifendem C ++ aufgegriffen, die bereits in CLion enthalten sind.
CLion-Kennzahlen zur Codeabdeckung funktionieren durch die Integration mit llvm-cov / gcov-Tools. In diesem Fall können Sie sowohl Unit-Tests als auch reguläre Konfigurationen ausführen. Entsprechend ihrer Ausführung wird die Ausführungshäufigkeit bestimmter Codezeilen berechnet. Die Ergebnisse mehrerer Starts können, falls gewünscht, allgemein zusammengefasst werden.
Sie können die Ergebnisse entweder direkt in einem speziellen Coverage-Fenster anzeigen:
... oder ganz links im Editor.
Nun, und vor allem: Damit dies funktioniert, müssen Sie spezielle Kompilierungsoptionen übergeben:
- Für GCC:
-fprofile-arcs -ftest-coverage oder --coverage . - Für Clang: entweder die gleichen Flags wie bei GCC oder
-fprofile-instr-generate -fcoverage-mapping . Unterschiede bestehen nur in der Methode zum Zusammenstellen von Abdeckungsmetriken.
Warum übergibt CLion selbst diese Parameter nicht? Meistens, weil wir die Regel haben, den Kompilierungsprozess nicht zu stören. Ja, und es ist nicht immer klar, wo diese Parameter übergeben werden sollen, wenn CMake nicht verwendet wird. Aber jetzt überlegen wir, wie wir solche Fälle in Zukunft automatisieren können (wir haben ein ähnliches Problem mit Desinfektionsmitteln).
Weitere Informationen zu Kompilierungsoptionen und zum Anzeigen von Metriken in CLion finden Sie in unserer
Online-Hilfe .
Andere Verbesserungen
Unter anderen wichtigen Verbesserungen in dieser Version:
- Unterstützung für das WSL2-Subsystem. Die Einstellungen in CLion stimmen mit denen der ersten Version von WSL überein.
- Unterstützung für Formatierungs- und Namensregeln von Microsoft. Dieser Stil ist auf einer Stufe mit Google, LLVM, Qt, GNU, Stroustrup und anderen unter Einstellungen / Voreinstellungen | verfügbar Herausgeber | Code Style | C / C ++.
- IntelliJ Rust Plugin Updates (ein ausführlicher Beitrag in unserem englischsprachigen Blog widmet sich diesen Änderungen).
- VCS unterstützt Updates, Benutzeroberflächen und andere Änderungen von der IntelliJ-Plattform.
Demo
Abschließend ein traditionelles Video über die neuen Funktionen von CLion 2019.3 (in englischer Sprache):
Vielen Dank für das Lesen bis zum Ende! Sie haben sicherlich Fragen, Wünsche, Fehlerberichte und nur Gedanken - wir warten in den Kommentaren darauf! Wie immer beantworten und diskutieren wir gerne Ihre Ideen.
Ihr JetBrains CLion-Team
Der Antrieb zur Entwicklung