通常の Kotlin プロジェクトではソースセットを使用することで、異なるプラットフォームごとにコードを分離することができます。MPS ではこれをルートレベルで導入し、Kotlin ルートノードごとにサポート対象プラットフォームのセットを指定するオプションを実装しました。これらのソースセットは、インテンションアクションを使用してルートノードレベルで構成できます。

実際の開発では、以下のメリットがあります。

• 特定のソースセットに含まれるコードから互換性のあるプラットフォームの宣言にのみアクセスできます。たとえば、JVM 固有のコードは JVM 固有のコードと JVM をターゲットする共通コードにのみアクセスできます。
• 生成されたソースがソースセット固有のディレクトリの下で構造化されます。ディレクトリが指定されていない場合は、モジュールのデフォルトに対応するデフォルトのソースセットが使用されます。
• expected および actual 宣言がサポートされるようになりました。

デフォルトではプラットフォームが明示的に指定されていない Kotlin コードは JVM を使用するため、下位互換性が維持されます。

MPS の Kotlin コードは CodeRules ベースの Kotlin Typesystem プラグインが利用できない場合に多数の typesystem エラーとスコープエラーを発生させていました。可読性とテスト可能性を改善するため、該当するチェックとエラーを CodeRules ベースの typesystem プラグインを利用できない場合にはミュートするようにしました。

その場合は Kotlin 言語のすべてのスコープが互換性のある概念のすべてのノードを含むデフォルトのスコープに置き換えられます。これによってすべての有効なノードがスコープに収まり、誤検出エラーがなくなります。

Kotlin コードの取り扱いに関するガイドラインは以前と同じままです。

• Kotlin コードの作成とチェックは、CodeRules が有効で Kotlin Typesystem プラグインがインストールされている状態で実行する必要があります。
• Kotlin の読み取りと生成は、これらがなくても安全に実行できます。

Logical View（論理ビュー）ペインに非同期アーキテクチャベースが採用されたことで、UI の応答性はそのままに IDE の全体的なパフォーマンスが改善されました。この新しい実装により、拡張と変更もさらに容易になりました。詳細については、ナレッジベースの「ProjectPane implementation on top of ProjectViewTree」という記事をご覧ください。

この新しい実装により、次のいくつかの重要な変更が発生しました。

• エラーと警告のインジケーターが提供されなくなりました。
• 階層内で見つかったエラーと警告がいずれも赤の下線で表示されるようになりました。
• Show Descriptor Models（記述子モデルを表示する）オプションがすべての記述子モデルに影響するようになりました。
• 一部のドラッグアンドドロップ操作の動作が変わっています。
• Logical View（論理ビュー）ペインの設定が少しだけ模様替えされています。

新しいスタイルを BaseLanguage に導入しました。このスタイルを使用すると、値（子ノードまたは参照）が欠落している場合に定数セルをプレースホルダーとして機能させることができます。たとえば、クラスにコンストラクターが存在しない場合は <no default constructor> プレースホルダーセルを代わりに表示することができます。このスタイルにより、定数セルがプレースホルダーセルに期待される動作を示すようになります。カーソルは最初の位置にのみ配置でき、値を編集することはできません。関連付けられた変換メニューによる変更のみが可能です。

ビルド言語のモジュールの doNotCompile ブール値オプションが Java 列挙型に置き換えられたため、以下のケースを区別しやすくなりました。

• モジュールにまったくコードが含まれていない。
• モジュールにコードが含まれているが、コードが MPS 以外のツールでコンパイルされている。

従来は上記のどちらのケースも値 true で表現されていました。

新しい Java 列挙型では、以下の 3 つの値が可能です。

• compile in MPS
• compile externally
• no code

2024.1 に移行する場合、doNotCompile の元の false 値は compile in MPS に移行され、doNotCompile の true 値は compile externally に移行されます。

小さな新しい実験的機能により、フォーク対象の元のプランを実際に変更せずに生成プランのフォークを追加できるようになっています。生成プランは別の生成プランのフォークとしてマークできます。マークされたプランは明示的な参照であるかのように扱われ、フォークされた生成プランの先頭に標準の fork ステートメントが追加されます。

また、フォークを定義する際にはトリガーとして機能する文字列修飾子を使用できます。このフォークは、生成対象モデルが文字列トリガーに一致するファセット ID を持つ生成ターゲットファセットを含むモジュールによって所有されている場合にのみ発生します。

MPS の JUnit テストで Vintage 形式と Jupiter 形式でだけでなく、Open Test Reporting 形式でもテストレポートを生成できるようになりました。ビルド言語のテストオプションでは、生成されたレポートに Open Test レポートが含めるかどうかを設定するための新しいオプションが提供されています。このオプションが true に設定されている場合、junit-platform-events*-$BUILD_NAME$.xml という名前のレポートファイルがプロジェクトディレクトリに作成されます。

このオプションが false の場合は従来の Vintage および Jupiter エンジンのレポートが作成されます。

MPS のテストレポートが JUnit の @DisplayName アノテーションを認識し、テストレポートツールウィンドウに表示されるレポートに名前を伝搬するようになりました。