In a regular Kotlin project, you can use source sets to separate code targeting different platforms. In MPS, we introduced this at the root level, with the option to specify the set of supported platforms for each Kotlin root node. These source sets can be configured at the root node level with the help of an intention action.

In practice, this means that:

• Code under a given source set can only access declarations with compatible platforms. For example, code specific to the JVM may access only JVM-specific code and common code that targets the JVM.
• Generated sources are structured under source-set-specific directories. If a directory is unspecified, it uses the default source set, which corresponds to the module’s default.
• Expected and actual declarations are now supported.

By default, Kotlin code without an explicit platform uses the JVM, maintaining backward compatibility.

Kotlin code in MPS used to raise a lot of typesystem and scope errors when the Kotlin Typesystem plugin, based on CodeRules, was not available. In order to improve readability and testability, these checks and errors are now muted when the CodeRules-based typesystem plugin is not available.

In such cases, all scopes in Kotlin languages are replaced with a default scope including all nodes of compatible concepts. This removes any false-positive errors, as all valid nodes are in the scope.

The guidelines for dealing with Kotlin code remain the same as before:

• Writing and checking Kotlin code should be done with CodeRules enabled and the Kotlin Typesystem plugin installed.
• Reading Kotlin and generating it can be safely performed without them.

The Logical View pane is now based on an asynchronous architecture, which helps keep the UI responsive and contributes to the overall performance of the IDE. The new implementation also allows for easier extensions and modifications. For more details, refer to our article in the knowledge base entitled ProjectPane implementation on top of ProjectViewTree.

This new implementation has resulted in a few notable changes:

• Error and warning indicators are no longer available.
• Both errors and warnings found in the hierarchy are underlined in red.
• The Show Descriptor Models option affects all descriptor models.
• Some drag-and-drop operations work differently.
• The settings in the Logical View pane have been reorganized slightly.

We’ve introduced a new style into BaseLanguage that allows constant cells to serve as placeholders if there’s a missing value (a child node or a reference). For example, when no constructor is present in a class, a <no default constructor> placeholder cell can be displayed instead. The style causes constant cells to exhibit the behavior you would expect from such placeholder cells. The cursor can only be placed on the first position, and it is not possible to edit the value. Only modifications provided by attached transformation menus are permitted.

The Boolean doNotCompile option of modules in the build language has been replaced with a Java enum to better distinguish the cases when:

• The module contains no code at all.
• The module contains code, but the code is compiled by tools other than MPS.

Both of these cases used to be represented by the value true.

The new Java enum has three possible values:

• compile in MPS
• compile externally
• no code

When migrating to 2024.1, the original false value of doNotCompile will be migrated to compile in MPS, while the true value of doNotCompile will be migrated to compile externally.

A small experimental new feature enables you to add a fork for a generation plan without actually modifying the original plan that is being forked. A generation plan can be marked as a fork of another generation plan. The marked plan will be treated as if it were referred to explicitly with the standard fork statement inserted at the very beginning of the forked generation plan.

Additionally, when defining a fork, you can use a string modifier that will serve as a trigger. The fork will only happen if the model being generated is owned by a module that has a generation target facet with a facet ID matching the string trigger.

JUnit tests in MPS can now generate test reports not only in the Vintage and Jupiter formats, but also in the Open Test Reporting format. A new option is available in the build language’s test options to control whether the Open Test report is included in the generated reports. If the option is set to true, report files named junit-platform-events*-$BUILD_NAME$.xml are created in the project directory.

If the option is set to false, the legacy reports for Vintage and Jupiter engines are created.

MPS test reports now respect the JUnit @DisplayName annotation and propagate the name to reports shown in the test report tool window.