CLion 2020.2: Unterstützung für Makefile-Designmodelle, mehr C ++ 20 und mehr

Hallo Habr!



Unser Team hatte einen sehr arbeitsreichen Sommer, dessen Ergebnisse wir heute in Eile veröffentlichen möchten. So begrüßt die neue Version von CLION 2.020,2!







Kurz darüber, was in der neuen Version enthalten ist :

• Unterstützung für Makefile-Designmodelle.
• Neueste Updates in CMake.
• C++20: explicit(bool), (designated initializers), for .
• : (dangling pointers), , , , .
• -: doctest, Catch2 Google Test. .
• PlatformIO .
• .
• .
• .

Makefile

Nach dem fünften Jahrestag von CLion in diesem Frühjahr haben wir uns sofort an der aktiven Fertigstellung des am meisten erwarteten Features in der IDE beteiligt - der Unterstützung von Projekten, die auf dem Makefile basieren. Vorher hatten wir nur einen groben Prototyp, den wir unseren mutigsten Benutzern zum privaten Ausprobieren gaben. Dank ihnen konnten wir den Prototyp an einer großen Auswahl von Makefile-Projekten testen, viele Probleme darin beheben und die aktuellen (hoffentlich vorübergehenden) Einschränkungen unserer Lösung verstehen. Unser Ziel ist es, Benutzern die Arbeit mit einem Makefile-Projekt in CLion mit allen intelligenten IDE-Funktionen wie Navigation, Refactorings, statischer Code-Analyse und anderen zu ermöglichen.



Der aktuelle Ansatz in Kürze sieht folgendermaßen aus: CLion führt einen Befehl makefür Ihr Projekt mit einer zusätzlichen Option aus--just-printum Zeit bei der eigentlichen Montage zu sparen. Wenn CLion die Befehlsausgabe erfolgreich analysieren kann, wird das Projekt geöffnet und alles funktioniert!



Machen wir gleich einen Vorbehalt, dass die Arbeit an der Makefile-Unterstützung in CLion noch lange nicht abgeschlossen ist - es sind noch viele Einschränkungen und Unvollkommenheiten bekannt. Am bemerkenswertesten:

• Projekte mit libtool ( CPP-19549 ), distcc und ccache ( CPP-19305 ) und anderen Wrappern, die Kompilierungsflags vor der Ausgabe "verbergen" oder die Befehlsausgabe beeinträchtigen, werden nicht unterstützt make.
• CLion ist noch nicht in der Lage, Nicht-GNU-Makes-Ausgaben (z. B. NMake, BSD) ( CPP-18723 ) zu verarbeiten.
• Projekte, die die Auflistung von Verzeichnisnamen während des Erstellungsprozesses deaktivieren, werden nicht unterstützt, sodass CLion nicht bestimmen kann, auf welche Dateien sich die einzelnen Erstellungsbefehle beziehen.

Aber auch mit der aktuellen Lösung können Sie den Linux-Kernel oder den PostgreSQL-Datenbankservercode in CLion öffnen. Bei Interesse finden Sie auf dieser Seite die aktuelle Liste der Projekte, bei denen unser Prototyp funktioniert (sowie einige Projekte, bei denen er nicht funktioniert, mit den angegebenen Problemen) .



Es ist sehr einfach, Ihr Projekt anzuprobieren:

1. Bereiten Sie ein Projekt vor, um ein Makefile dafür zu erhalten (in vielen Fällen müssen Sie es beispielsweise starten ./configure, da CLion selbst noch nicht weiß, wie dies zu tun ist).
2. Öffnen Sie ein Projekt mit Datei | Öffnen und geben Sie das Verzeichnis an, das das Makefile des Hauptprojekts enthält, oder direkt diese Datei. Bestätigen Sie, dass Sie als Projekt öffnen möchten.
3. CLion , Clean. , make , .
4. , , ! Build.

Die Ausgabe enthält möglicherweise einige Warnungen. Wenn der Download jedoch insgesamt erfolgreich abgeschlossen wurde (neben der ersten Aufgabe sollte eine grüne Markierung angezeigt werden), können Sie mit dem Projekt in CLion arbeiten.



Die Einstellungen für die Startbefehlsargumente, die zum Booten verwendete Toolchain und andere Optionen finden Sie unter Einstellungen / Einstellungen | Erstellen, Ausführen, Bereitstellen | Makefile:







Um Makefile-Anwendungen auszuführen und zu debuggen, müssen Sie zusätzliche Makefile-Anwendungskonfigurationen erstellen. In diesem Fall kann das Ziel aus der Dropdown-Liste ausgewählt werden. CLion teilt Ihnen mit, welche Optionen verfügbar sind:







In unserem Blog auf Englisch finden Sie weitere Informationen zum Arbeiten mit Makefile-Projekten in CLion. Wir empfehlen außerdem eine kurze Demo (auf Englisch):

Neueste Updates in CMake

Wie Statistiken zeigen , sind CMake, msbuild und Makefile die drei beliebtesten Designmodelle unter C ++ - Entwicklern. Und es ist CMake, der dieses Rating seit drei Jahren anführt und weiter wächst. Aus diesem Grund aktualisieren wir ständig die in CLion verbotene Version von CMake und arbeiten daran, die neuesten Innovationen in CMake selbst zu unterstützen. Dieses Mal haben wir die Version auf 3.17 aktualisiert und dementsprechend Unterstützung für zwei neue nützliche CMake-Funktionen hinzugefügt:

• Ninja Multi-Config ( Debug Release) Ninja ( -G "Ninja Multi-Config"). CLion , CMake . UI, .
• Vorkompilierte CMake-Header verdienen mehr Aufmerksamkeit. Im Allgemeinen ist die Idee vorkompilierter Header-Dateien (PCH) nicht neu und wird von Compilern seit langem unterstützt. CLion ist auch schon seit einiger Zeit bei PCH. Jetzt müssen Sie sich nicht mehr die Compiler-Flags für PCH merken und sie auf Ihre eigene Weise an CMake an jeden bestimmten Compiler übergeben, sondern fügen einfach die Header-Dateien über den Befehl zu den PCH-Zielvariablen hinzu target_precompile_headers. CLion 2020.2 kann jetzt damit arbeiten:
  
  
  
  

Bemerkenswert ist auch die Möglichkeit, ein CMake-Projekt in CLion aus dem Verzeichnis mit dem Ergebnis der CMake-Generierung zu öffnen, jetzt nicht nur für den Makefile-Generator, sondern für jeden anderen! Zeit sparen - Öffnen Sie bereits erstellte Projekte in CLion, ohne den CMake-Befehl für das Projekt neu zu starten.

C ++ 20

Wussten Sie, dass nach unseren Angaben in diesem Jahr bereits 12% der C ++ - Entwickler den C ++ 20-Standard verwenden ?! Daher arbeiten wir natürlich aktiv daran, neue Funktionen in CLion zu unterstützen. Aber denken wir zuerst daran, was wir mit Sprach-Engines in CLion haben.



Im Moment gibt es also zwei davon - eine integrierte auf Java / Kotlin-Basis und eine ziemlich neue auf Clangd-Basis in C ++ (wir verwenden CLion für die Entwicklung). Alle Anstrengungen werden jetzt in eine Clangd-basierte Engine gesteckt. Es scheint eine gute Perspektive zu sein, obwohl noch keine Aktionen für das gesamte Projekt (wie Refactorings) durchgeführt werden können - hier gewinnt sogar eine unvollständige und manchmal langsame Java-basierte Engine aufgrund aller möglichen spezifischen Optimierungen und verzögerten Auflösungen und natürlich aufgrund des Vorhandenseins eines Caches Symbole für Refactorings benötigt.



Aber Clangd hat ein sehr großes Plus: Die gesamte Community arbeitet dort daran, die neuesten C ++ - Standards in Clang zu unterstützen, da das Projekt offen ist. Dies bedeutet natürlich nicht, dass wir überhaupt nichts tun müssen - diese Unterstützung muss ohnehin noch an die Bedürfnisse von CLion angepasst werden. Dies ist jedoch bereits einfacher, als die Unterstützung für C ++ - Funktionen von Grund auf neu zu schreiben! Auf der Grundlage der Unterstützung in Clang können Sie Ihre eigene spezifische Analyse schreiben oder einige spezielle Funktionen ausführen (z. B. haben wir vor einigen Releases die automatische Vervollständigung für Concepts durchgeführt ).



Wir haben sichergestellt, dass sich das neueste Update der Clangd-Engine, das mit LLVM geliefert wurde, im C ++ 20-Code stabiler verhält, und gemäß unserer integrierten Statistik ist die Clangd-Engine im Allgemeinen stabiler geworden. Daher wurde die Möglichkeit, die Clangd-Engine vollständig zu deaktivieren, aus den Einstellungen entfernt. Aber hinzugefügt zu Einstellungen / Einstellungen | Sprachen & Frameworks | C / C ++ | Klirrende Informationen über die Revision, mit der unser Motor gebaut wurde. Jetzt wissen Sie, was Sie von der Unterstützung von C ++ und der Analyse von Clang-Tidy erwarten können:







In unserer Online-Hilfe finden Sie übrigens einen hervorragenden Artikel mit einer vergleichenden Analyse der beiden Engines hinsichtlich der Unterstützung von C ++ - Funktionen.



Und nun zu dem, was tatsächlich von der C ++ 20-Unterstützung hinzugefügt wurde:

• Code - Vervollständigung für C ++ 20 Stichworte: char8_t, consteval, und constinit, co_await, co_return, und co_yield.
• Vervollständigung für Felder aus der Basisklasse in festgelegten Initialisierern:
  
  
  
  
• Das Konstrukt ist explicit(bool)jetzt korrekt hervorgehoben, Namenshinweise, Navigation und Refactorings funktionieren darin:
  
  
  
  
• Bei forbereichsbasierten Schleifen mit Initialisierern funktionierte das Umbenennen für Schleifenvariablen.

Statischer Code-Analysator

In der letzten Version haben wir unsere „schwerste“ Analyse - die Datenflussanalyse - auf eine Clangd-basierte Engine übertragen. Dies dient hauptsächlich der Verbesserung der Leistung. Aber wie so oft wurden beim Refactoring viele Probleme und Ungenauigkeiten festgestellt. In Release 2020.2 haben wir diese Analyse weiter verbessert und Fehler darin behoben:

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

In dieser Version wurde aus jedem beliebten Inspection Hector (über den sich einige unserer Benutzer vergeblich lustig gemacht haben ) ein neues Inspection Widget in der oberen rechten Ecke des Editorbereichs. Jetzt befinden sich dort die Optionen zum Einstellen der Hintergrundbeleuchtung (von der Anzeige aller Probleme bis zur vollständigen Deaktivierung des Code-Analysators). Wenn Sie auf klicken, wird ein Fenster mit statischen Analyseergebnissen für diese Datei geöffnet:

Unit Testing

Die hier bereits mehr als einmal erwähnte Untersuchung zeigt, dass 34% der C ++ - Entwickler keine Unit-Tests schreiben . Ich würde gerne glauben, dass sie im Gegenzug Tests auf andere Weise durchführen. Ein Teil des Problems besteht darin, dass C ++ kein Standarddesignmodell oder keinen Standardabhängigkeitsmanager hat, was bedeutet, dass das Hinzufügen eines Unit-Test-Frameworks zu Ihrem Projekt nicht einfach ist. Aber jetzt werden die sogenannten Nur-Header-Frameworks besonders beliebt, die sich leicht mit Ihrem Projekt verbinden lassen - fügen Sie eine Header-Datei hinzu und schreiben Sie sich selbst Tests. Unsererseits versuchen wir in der IDE, so viele Optionen wie möglich zu unterstützen. In dieser Version wurde doctest aus Google Test, Catch, Boost.Test zum Set hinzugefügt. Übrigens hatten wir vor einiger Zeit einen Gast-Blog-Beitragvon seinem Autor, wo Viktor über die Vorteile dieses Frameworks sprach.



Die CLion-Unterstützung umfasst die üblichen Dinge:

• Automatische Testerkennung.
• Automatische Erstellung von Konfigurationen zum Ausführen und Debuggen von Tests.
• Die Ausgabe der Testergebnisse erfolgt in einem speziellen integrierten Fenster mit verschiedenen Filter- und Bestelloptionen sowie einem Übergang zum Testquellcode mit einem Klick.
• Symbole im Editor im linken Bereich zum Ausführen von Tests und zum Identifizieren des Status des letzten Testlaufs.

Die Unterstützung für Google Test und Catch2 wurde ebenfalls aktualisiert:

• Unterstützung für Vorlagentests wurde für Catch2 hinzugefügt.
• Und für Google Test Unterstützung für ein Makro GTEST_SKIP(), was sehr nützlich sein kann, wenn Sie einige Tests beispielsweise in bestimmten Umgebungen überspringen möchten.

Ein kleines Übersichtsvideo über Verbesserungen bei der Unterstützung von Unit-Tests durch unseren Anwalt (übrigens der Autor des Catch / Catch2-Frameworks):





Warnen Sie Ihre Fragen zu CTest: Machen Sie es etwas schwieriger, da dies kein „reguläres“ Framework ist, sondern eine bestimmte Abstraktionsebene, um etwas in Form eines Tests auszuführen. Wir planen jedoch bereits 2020.3 eine Integration!

Und auch

Das vielleicht interessanteste diskutierte jetzt kurz über den Rest. Ich hätte damit beginnen sollen, aber CLion 2020.2 enthält viele kleine, aber wichtige Verbesserungen der Editorleistung und der Korrekturen für Editor-Hänge. Eine solche Verbesserung ist beispielsweise das Einfügen eines Backslashs, wenn Enter innerhalb einer Makrodefinition gedrückt wird . Es scheint, dass dies die Produktivität des Editors fördert? Tatsache ist, dass die neue Zeile höchstwahrscheinlich Teil der Definition des aktuellen Makros ist. Durch das Einfügen eines Backslashs können Sie unnötiges erneutes Analysieren einer Reihe von Codes und damit die Bremsen des Editors vermeiden.



Außerdem:

• PlatformIO — , platformio.ini CMake .
• , IntelliJ . : GitHub Pull Requests Git WSL2 ( WSL2, CLion Git ).
• In Bezug auf die Debugger im Jahr 2020.2 konnten wir weniger als geplant tun. Grundsätzlich wurden alle großen Aufgaben auf 2020.3 zurückgeschoben (Debuggen als Root, Debuggen von Core Dumps). Aber in dieser Version haben wir die gesperrte Version von GDB auf 9.2 aktualisiert und auch die hübschen GDB STL-Drucker aktualisiert. In unserem LLDB-basierten Debugger für die Microsoft Visual C ++ - Toolchain wurden viele Verbesserungen in Bezug auf Funktionalität, Leistung und Stabilität vorgenommen.

Das ist alles für heute. Hast du bis zum Ende gelesen? Vielen Dank für Ihre Aufmerksamkeit! Probieren Sie es aus , schreiben Sie Fragen, Vorschläge, Ausrufezeichen in die Kommentare - wir lesen und beantworten sie gerne!



CLion Team

Der Antrieb zur Entwicklung