Hallo Habr!
Der Sommer vor dem Fenster vergeht für uns fast unmerklich, da wir all diese Monate der Arbeit an der neuen Version 2019.2 unserer plattformübergreifenden Entwicklungsumgebung für C ++ - CLion gewidmet haben. Wir haben eine Menge Dinge geschafft: einen internen Hackathon durchführen, neue Ideen ausprobieren und eine Reihe von Korrekturen und neuen Funktionen sofort veröffentlichen. Aber das Wichtigste zuerst.

Kurz gesagt, in dieser Version haben wir:
- Wir haben die Unterstützung für die Entwicklung eingebetteter Systeme weiter verfeinert: Neue Debugging-Funktionen und Anzeige von Peripheriegeräten wurden veröffentlicht.
- Der experimentelle Debugger für MSVC wurde auf eine akzeptable Qualität gebracht.
- Wir haben die Codeüberprüfung für nicht verwendete Includes bei clangd komplett neu geschrieben und die Möglichkeit hinzugefügt, verschiedene Strategien zu konfigurieren.
- Implementierte Hinweise für Funktionsaufrufargumente und Lambdas zur Verbesserung der Lesbarkeit von Code.
- Wir haben einen teaminternen Hackathon durchgeführt, um die Produktivität zu verbessern, eine Reihe neuer Ansätze entwickelt und mehrere Verbesserungen umgesetzt.
- Wir haben die Syntaxhervorhebung für mehr als 20 Sprachen implementiert, ein Shell Script-Plugin integriert und das Rust-Plugin aktualisiert.
Das ist natürlich
nicht alles . Wir werden im Folgenden ausführlicher darauf eingehen. Wenn Sie jedoch bereit sind, es jetzt zu versuchen, laden Sie den Build von
unserer Website herunter . Wie üblich steht eine kostenlose Testversion für 30 Tage zur Verfügung.
Neue Funktionen für die Embedded-Entwicklung
In der letzten Version dachten viele aus irgendeinem Grund, dass wir uns nur auf STM32-Boards konzentrierten. Dies ist natürlich einer der interessantesten und umfangreichsten Märkte in vielen Studien (einschließlich unserer inländischen), aber wir versuchen jetzt, allgemeinere Probleme zu lösen. Zum Beispiel haben wir die Debugging-Funktionen auf verschiedenen Boards von CLion erweitert.
Bisher war die einzige Option die Konfiguration für den OpenOCD-Debugger - OpenOCD Download & Run. Jetzt ist ein weiterer erschienen - Embedded GDB Server. Wenn das Board das Debuggen über einen kompatiblen GDB-Server unterstützt, können Sie es über CLion debuggen. Die Konfiguration umfasst Fälle wie OpenOCD, ST-Link GDB-Server, Segger J-Link GDB-Server, QEMU und mehr.

Es reicht aus, die entsprechende Konfiguration zu erstellen und zu konfigurieren - geben Sie den Pfad zum GDB-Server, die Argumente, die Sie an ihn übergeben, und möglicherweise einige erweiterte Einstellungen an. Führen Sie nun das Debuggen in dieser Konfiguration aus, und Sie können direkt von CLion aus auf dem Board debuggen!
Es gibt eine wichtige Einschränkung, die jetzt beide Konfigurationen für das Debuggen eingebetteter Systeme betrifft - beide funktionieren derzeit nur mit Projekten auf CMake. In Zukunft planen wir, die Möglichkeit hinzuzufügen, sie für benutzerdefinierte
Designmodelle (
CPP-16079 ) auszuführen.
Für beide vorhandenen Debugging-Konfigurationen eingebetteter Systeme (Embedded GDB Server und OpenOCD Download & Run) bietet die neue Version jetzt die Möglichkeit, Peripheriegeräte während des Debuggens anzuzeigen. Im Allgemeinen werden Peripheriegeräte für Geräte der ARM-Familie in
Dateien im
SVD- Format
angegeben . Diese Spezifikationen können jetzt in CLion geladen werden und die ausgewählten Peripheriegeräte direkt im Debugger-Fenster anzeigen:

Alle Peripheriegeräte sind weiterhin im schreibgeschützten Modus verfügbar, während nach Namen gesucht wird und Werte in verschiedenen Modi (hexadezimal, dezimal, oktal und binär) angezeigt werden können. Mehr dazu lesen Sie in unserem
Blog (auf Englisch).
Experimenteller Debugger für MSVC
Sie haben es richtig gelesen - in Release 2019.2 hat CLion einen experimentellen Debugger für Code eingeführt, der mit MSVC kompiliert wurde! Lassen Sie uns nun etwas detaillierter und in Ordnung verstehen.
In CLion können Sie lange Zeit nicht nur die MinGW- und Cygwin-Toolchain verwenden, sondern auch Visual Studio, wenn Sie auf der Windows-Plattform entwickeln. Sie geben den Pfad zum installierten VS in CLion an und von dort verwenden wir den MSVC-Compiler und die Skripts, um die Umgebung zu konfigurieren. Aber es gab lange Zeit Probleme mit dem Debugger. Tatsache ist, dass der von Visual Studio selbst verwendete Debugger proprietär ist. Einfach ausgedrückt, nirgendwo anders als bei Microsoft-Tools kann es unter Lizenz verwendet werden. Es gibt eine alternative Technologie -
dbgeng.dll , auf der CDB- und WinGDB-Debugger implementiert sind. Das erste, was wir getestet haben, war sie. Es schien uns jedoch nicht sehr vielversprechend, mit der Anzahl kritischer Abstürze und der schlechten Leistung von Binärdateien mit einer großen Anzahl von PDB-Dateien umzugehen (obwohl wir es zunächst versucht haben). Und dann stellte sich heraus, dass es eine dritte Option gibt - einen Debugger zusätzlich zu LLDB zu implementieren. Es gab bereits Erfolge, und wir mussten diese Arbeit nur fortsetzen. Was wir gemacht haben! Übrigens haben wir alle unsere Änderungen (mit Ausnahme der Unterstützung von nativen Datenvisualisierern) in den LLVM-Assistenten übernommen.
Wie aktiviere ich? Wie ich bereits schrieb, ist die Gelegenheit noch experimentell. Es ist zu früh, einen Debugger als vollwertig zu bezeichnen, er weist viele Einschränkungen und Mängel auf, und die Leistung erfordert erhebliche Optimierungen. Diese experimentelle Funktion wird im Wartungsdialog aktiviert (
Shift+Ctrl+Alt+/
unter Linux / Windows,
⌥⇧⌘/
unter macOS) | Experimentelle Merkmale |
cidr.debugger.lldb.windows . Jetzt ist ein neuer Debugger für die Visual Studio-Toolchain verfügbar:

Der Debugger unterstützt zunächst native Visualisierer, die sowohl im Studio enthalten sind, als auch benutzerdefinierte benutzerdefinierte Visualisierer, die im Projekt enthalten sind. Derzeit muss die Funktion explizit in die Einstellungen aufgenommen werden: Einstellungen | Erstellen, Ausführen, Bereitstellen | Debugger-Datenansichten | Aktivieren Sie NatVis-Renderer für LLDB. In einem der ersten Updates planen wir, einige kritische Probleme mit Visualisierern zu beheben und sie dann wahrscheinlich standardmäßig zu aktivieren.

Wenn Sie einen neuen experimentellen Debugger ausprobieren möchten, empfehlen wir Ihnen, sich mit der Liste der bekannten Einschränkungen und Probleme in
unserem Blog vertraut zu machen.
Weitere Verbesserungen am Debugger
Neben dem neuen experimentellen Debugger haben wir eine Reihe weiterer Verbesserungen vorgenommen:
- In der integrierten GDB / LLDB-Konsole und im Debugger-Fenster in CLion funktioniert die automatische Vervollständigung der Debugger-Befehle jetzt (verwenden Sie die
Tab
oder Ctrl+Space
). - String-Haltepunkte werden jetzt im laufenden Betrieb überprüft und ihr Status wird aktualisiert und dem Benutzer in Form eines entsprechenden Symbols angezeigt. Der interessanteste Typ ist " Ungültig" , der hinzugefügt wurde, um Haltepunkte zu identifizieren, die im aktuellen ausführbaren Code nicht verfügbar sind oder für die keine Debugging-Symbole vorhanden sind (in diesem Fall wird der Status des Haltepunkts nach dem Laden automatisch aktualisiert).

- Beim Anzeigen des Speichers im Debugger (Speicheransicht) in der neuen Version wurde es möglich, zu einer beliebigen Adresse (nach numerischer Adresse oder Variablenname / -adresse) zu wechseln und den Speicher im ASCII-Format darzustellen:

Verbesserungen des Code-Editors
In diesem Bereich gibt es mehrere große Verbesserungen. Zuerst haben wir die Codeprüfung für
nicht verwendete Includes vollständig neu geschrieben und standardmäßig aktiviert. Früher war es auch dort, aber es gab eine große Anzahl von Fehlalarmen, so dass wir es standardmäßig deaktiviert haben. Warum wird es besser? Wir haben die Überprüfung basierend auf dem zweiten zusätzlichen Tool zum Parsen von Code, das wiederum auf Clangd basiert, komplett neu geschrieben. Dies ist also eine klare Einschränkung - die neue Version funktioniert nur, wenn Clangd für Sie nicht deaktiviert ist (standardmäßig ist es aktiviert). Bei der Suche nach nicht verwendeten Includes sind nun mehrere Strategien erschienen, zwischen denen Sie wählen können:

Standardmäßig wird "
Nicht direkt verwendet erkennen" verwendet. Dies entspricht im Wesentlichen dem bekannten Prinzip "
Einschließen, was Sie verwenden" . Wenn also Deklarationen aus der Header-Datei nicht direkt in dieser Datei verwendet werden, wird eine solche Header-Datei als nicht verwendet markiert.
In den Inspektionseinstellungen (Einstellungen / Einstellungen | Editor | Inspektionen | C / C ++ | Nicht verwendeter Code | Nicht verwendete Include-Direktive) können Sie auch auswählen, ob die Prüfung in den Header-Dateien selbst ausgeführt werden soll. Es
stimmt , es funktioniert nur in den Header-Dateien, in denen
#pragma oder Header-Guards vorhanden sind. Es ist auch wichtig zu wissen, dass bei der Überprüfung keine nicht verwendeten Dateien angezeigt werden, wenn Kompilierungsfehler in der Quelldatei vorhanden sind.
Seit der letzten Version unterstützt CLion
ClangFormat als alternatives Code-Formatierungswerkzeug zusätzlich zu dem integrierten. In dieser Version haben wir ein integriertes JSON-Schema für Konfigurationsdateien im Clang-Format hinzugefügt. Dank dessen konnten wir verschiedene Funktionen hinzufügen, die für diejenigen nützlich sein können, die die Dateien im CLang-Format in CLion ändern:
- Für Optionen und ihre Werte wurde die automatische Vervollständigung angezeigt.
- Im Fenster für die automatische Vervollständigung von Optionen finden Sie jetzt eine Beschreibung der Optionen.
- Das Dokumentationsfenster für die Schnelldokumentation (
Ctrl+Q
unter Windows / Linux, F1
unter macOS) zeigt die Dokumentation der Optionen und ihrer Bedeutung anhand von Beispielen. - Die Validierung von Optionen für gültige Werte wird hinzugefügt.

Tipps für Argumente
Was ist, wenn die Funktion so geschrieben ist (möglicherweise nicht von Ihnen), dass 3 Ganzzahlen als Argumente an sie übergeben werden? Wie kann man unter einem Funktionsaufruf verstehen, was die übertragenen Werte bedeuten? Natürlich können Sie die Funktionssignatur im Dokumentationsfenster sehen, zur Funktionsdefinition gehen oder die Parameterinformationen aufrufen (Parameter Info). Und wenn Sie diese expliziten Aktionen nicht ausführen?
In Version CLion 2019.2 wurden QuickInfos für Argumente angezeigt. Beim Aufrufen einer Funktion, eines Lambda, eines Konstruktors, einer Initialisierungsliste oder bei Verwendung eines Makros zeigt CLion die Parameternamen an, bevor die Argumente übergeben wurden:

Hinweise werden in Fällen angezeigt, in denen es wirklich schwierig ist zu verstehen, welche Werte an welche Parameter übergeben werden, nämlich wenn Literale oder Ausdrücke mit mehr als einem Operanden als Argumente verwendet werden.
Weitere Details im Blogbeitrag .
Leistung
Natürlich werden wir oft nach Leistungsverbesserungen gefragt. Ich wiederhole, für uns ist dies die vorrangigste Aufgabe, aber es stellt sich heraus, dass es nicht viele Punktänderungen gibt und globale Änderungen länger dauern als 1-2 Release-Zyklen. Jetzt gibt es einige so große Veränderungen in der Arbeit. Grundsätzlich hängen sie damit zusammen, wie der Parser in CLion mit der Plattformarchitektur interagiert (was im Fall von C ++ nicht immer berechnet, dass ein Code mit langer Auflösung hinter einer einfachen Aktion verborgen ist).
In diesem Sommer haben das Team und ich beschlossen, einen internen Hackathon abzuhalten, um die am stärksten gefährdeten Stellen in der CLion-Architektur und -Plattform zu identifizieren, neue mutige Ideen auszuprobieren und einige alte Hypothesen zu testen. Die Ergebnisse haben uns gefallen. Wenn möglich, planen wir, bis 2019.3 einige neue Ideen zur Veröffentlichung zu bringen.
Die Version 2019.2 blieb jedoch nicht ohne Leistungsverbesserungen:
- Wir haben viele der Verlangsamungen und Einfrierungen bei der Umgestaltung von In-Place Rename beseitigt.
- Verbesserte Leistung bei der automatischen Vervollständigung für qualifizierte Ausdrücke.
- Bei Remote-Arbeiten haben wir die Anzahl der E / A-Vorgänge reduziert, wodurch die Erfassung von Informationen über den Compiler und damit die Download-Geschwindigkeit des CMake-Projekts erheblich beschleunigt wurden.
- Und andere Verbesserungen.
Nicht nur C ++
Von der IntelliJ-Plattform in CLion 2019.2 wurden viele Verbesserungen für die Arbeit mit anderen Sprachen vorgenommen.
Die Syntaxhervorhebung von mehr als
20 Sprachen wird jetzt von TextMate-Grammatiken bereitgestellt (eine vollständige Liste der Sprachen finden Sie unter Einstellungen / Einstellungen | Editor | TextMate-Bundles). Wenn für diese Sprache eine erweiterte Unterstützung in CLion (Python, JavaScript, HTML, Objective-C, SQL) vorhanden ist, wird diese natürlich verwendet. Für Sprachen wie Ruby kann jedoch die einfachste Hervorhebung hilfreich sein:

In C ++ - Projekten gibt es häufig verschiedene
Skripte . Das Shell Script Plugin ist jetzt in CLion integriert. Es bietet nicht nur Code-Hervorhebung, sondern auch automatische Vervollständigung und Umbenennung von Text:
Das Rust- Plugin hat viele nützliche Updates erhalten. Von einem neuen experimentellen Makro-Erweiterungstool (Einstellungen / Einstellungen | Sprachen & Frameworks | Rust | Deklarative Makros erweitern) bis hin zu
doppelten Codefragmenten , verschiedenen neuen Schnellkorrekturen und automatischer Vervollständigung im Debugger in
Ausdrücke auswerten . Übrigens ist es in CLion, dass dieses Plugin jetzt unter allen IDEs von JetBrains am meisten genutzt wird!
Demo
Traditionelles Video über die neuen Funktionen von CLion 2019.2 (auf Englisch):
Das ist alles für einmal. Vielen Dank für das Lesen bis zum Ende! Fragen, Wünsche, Fehlerberichte und nur Gedanken kommen in den Kommentaren zum Ausdruck! Wir werden wie immer gerne antworten.
Ihr JetBrains CLion-TeamDer Antrieb zur Entwicklung