In einem normalen Kotlin-Projekt können Sie Quellcode-Sets verwenden, um Code für unterschiedliche Plattformen zu trennen. In MPS haben wir dies auf der Stammknoten-Ebene eingeführt, mit der Option, für jeden Kotlin-Stammknoten die unterstützten Plattformen anzugeben. Diese Quellcode-Sets können auf der Stammknoten-Ebene über eine Kontextaktion konfiguriert werden.

In der Praxis bedeutet dies Folgendes:

• Code in einem bestimmten Quellcode-Set kann nur auf Deklarationen zugreifen, deren Plattformen kompatibel sind. Zum Beispiel kann JVM-spezifischer Code nur auf JVM-spezifischen Code und Common-Code mit der Zielplattform JVM zugreifen.
• Die generierten Quellen werden in Quellcode-Set-spezifischen Verzeichnissen abgelegt. Wenn kein Verzeichnis angegeben ist, wird das Standard-Quellcode-Set verwendet, das der Standardeinstellung des Moduls entspricht.
• Erwartete und tatsächliche Deklarationen (expect/actual) werden jetzt unterstützt.

Standardmäßig verwendet Kotlin-Code ohne explizite Plattform die JVM, um die Abwärtskompatibilität zu wahren.

Kotlin-Code in MPS führte früher zu zahlreichen typesystem- und Scope-Fehlern, wenn das auf CodeRules basierende Kotlin-Typesystem-Plugin nicht verfügbar war. Um die Lesbarkeit und Testbarkeit zu verbessern, werden diese Prüfungen und Fehler jetzt stummgeschaltet, wenn das CodeRules-basierte Typesystem-Plugin nicht verfügbar ist.

In solchen Fällen werden alle Scopes in Kotlin-Sprachen durch einen Standard-Scope ersetzt, der die Knoten aller kompatiblen Concepts umfasst. Dies beseitigt alle Fehlalarme, da sich alle gültigen Knoten im Scope befinden.

Die Richtlinien für die Handhabung von Kotlin-Code bleiben unverändert:

• Das Schreiben und Prüfen von Kotlin-Code sollte mit aktivierten CodeRules und installiertem Kotlin-Typesystem-Plugin erfolgen.
• Das Lesen und Generieren von Kotlin-Code ist jedoch problemlos ohne diese möglich.

Die Logical View-Leiste verwendet jetzt eine asynchrone Architektur, die zur Reaktionsschnelligkeit der Bedienoberfläche beiträgt und die allgemeine IDE-Performance verbessert. Die neue Implementierung vereinfacht auch die Umsetzung von Erweiterungen und Änderungen. Für weitere Informationen lesen Sie bitte unseren Artikel ProjectPane implementation on top of ProjectViewTree in der Knowledge Base.

Diese neue Implementierung hat zu einigen erwähnenswerten Änderungen geführt:

• Fehler- und Warnanzeigen sind nicht mehr verfügbar.
• Sowohl Fehler als auch Warnungen, die in der Hierarchie gefunden werden, sind rot unterstrichen.
• Die Option Show Descriptor Models wirkt sich auf alle Deskriptor-Modelle aus.
• Einige Drag-and-Drop-Vorgänge funktionieren anders als bisher.
• Die Anordnung der Einstellungen in der Logical View-Leiste wurde leicht geändert.

Wir haben in der BaseLanguage einen neuen Stil eingeführt, der es ermöglicht, konstante Zellen als Platzhalter für fehlende Werte (untergeordnete Knoten oder Referenzen) zu verwenden. Wenn zum Beispiel kein Konstruktor in einer Klasse vorhanden ist, kann stattdessen die Platzhalterzelle <no default constructor> angezeigt werden. Der Stil bewirkt, dass konstante Zellen ein für Platzhalterzellen erwartbares Verhalten zeigen. Der Cursor kann nur auf die erste Position gesetzt werden, und der Wert ist schreibgeschützt. Erlaubt sind nur Änderungen, die durch zugeordnete Transformationsmenüs vorgenommen werden.

Die boolesche Option doNotCompile von Modulen in der Build-Sprache wurde durch ein Java-Enum ersetzt, um die folgenden Fälle besser zu unterscheiden:

• Das Modul enthält überhaupt keinen Code.
• Das Modul enthält Code, aber der Code wird nicht von MPS, sondern von anderen Tools kompiliert.

Beiden Fällen entsprach früher der Wert true.

Das neue Java-Enum hat drei mögliche Werte:

• compile in MPS
• compile externally
• no code

Bei der Migration auf 2024.1 wird in der Option doNotCompile der Wert false in compile in MPS und der Wert true in compile externally geändert.

Eine experimentelle neue Funktion ermöglicht das Forken eines Generierungsplans, ohne den ursprünglichen Plan, auf dem der Fork basiert, zu verändern. Ein Generierungsplan kann als Fork eines anderen Generierungsplans gekennzeichnet werden. Der gekennzeichnete Plan wird so behandelt, als würde er explizit mit der üblichen fork-Anweisung am Anfang des geforkten Generierungsplans referenziert.

Darüber hinaus können Sie beim Definieren eines Forks einen Modifikator-String verwenden, der als Trigger dient. Der Fork wird nur erstellt, wenn das zu generierende Modell einem Modul angehört, das ein Generierungsziel-Facet besitzt, dessen Facet-ID mit dem Trigger-String übereinstimmt.

JUnit-Tests in MPS können jetzt Testberichte nicht nur in den Formaten Vintage und Jupiter, sondern auch im Open-Test-Reporting-Format erzeugen. In den Testoptionen der Build-Sprache steht eine neue Option zur Verfügung, mit der Sie festlegen können, ob der Open-Test-Bericht in den generierten Berichten enthalten sein soll. Wenn die Option auf true gesetzt ist, werden im Projektverzeichnis Berichtsdateien mit dem Namen junit-platform-events*-$BUILD_NAME$.xml angelegt.

Wenn die Option auf false gesetzt ist, werden Berichte in den Altformaten Vintage und Jupiter erstellt.

MPS-Testberichte berücksichtigen jetzt die @DisplayName-Annotation von JUnit und übernehmen den Namen in die Berichte, die im Testbericht-Toolfenster angezeigt werden.