В обычном проекте Kotlin вы можете использовать исходные наборы для разделения кода, предназначенного для разных платформ. В MPS эта возможность реализована на уровне корня: можно указать набор поддерживаемых платформ для каждого корневого узла Kotlin. Исходные наборы можно настроить на уровне корневого узла с помощью intention-действия.

На практике это означает следующее:

• Коду из определенного исходного набора доступны только объявления на совместимых платформах. Например, код для JVM получает доступ только к коду, предназначенному для JVM, и общему коду, для которого JVM является целевой платформой.
• Сгенерированные исходники распределяются по директориям исходных наборов. Если директория не определена, используется исходный набор по умолчанию, соответствующий настройкам по умолчанию для модуля.
• Мы обеспечили поддержку ожидаемых и фактических объявлений.

По умолчанию код Kotlin, для которого платформа не указана явно, использует JVM, гарантируя обратную совместимость.

Раньше в коде Kotlin в MPS обнаруживалось множество ошибок typesystem, а также ошибок области доступа, если был недоступен плагин Kotlin Typesystem на основе CodeRules. Чтобы улучшить читаемость кода и его пригодность для тестирования, мы дали возможность игнорировать эти проверки и ошибки, если плагин на основе системы типов CodeRules недоступен.

В таких случаях все области доступа в языках Kotlin заменяются областью по умолчанию, которая включает в себя все узлы совместимых концептов. В результате ложные срабатывания отсутствуют, поскольку все действительные узлы включены в область доступа.

Инструкции по работе с кодом Kotlin не изменились:

• Писать и проверять код на Kotlin следует, включив CodeRules и установив плагин Kotlin Typesystem.
• Читать и генерировать Kotlin можно и без них.

Теперь в основе панели Logical View лежит асинхронная архитектура. Это помогло сократить отклик интерфейса и в целом повысить производительность IDE. Кроме того, новая реализация упрощает добавление расширений и модификаций. Подробнее см. в статье базы знаний Реализация панели ProjectPane поверх дерева ProjectViewTree (на английском языке).

Это привело к несколькими заметным изменениям:

• Индикаторы ошибок и предупреждений больше недоступны.
• Как ошибки, так и предупреждения, обнаруженные в иерархии, подчеркиваются красным.
• Параметр Show Descriptor Models распространяется на все модели дескрипторов.
• В некоторых случаях перетаскивание работает по-новому.
• Настройки на панели Logical View были немного реорганизованы.

Мы добавили новый стиль в BaseLanguage, который позволяет использовать постоянные ячейки в качестве плейсхолдеров, если отсутствует значение (дочерний узел или ссылка). Например, если в классе нет конструктора, вместо него может отображаться ячейка-плейсхолдер <no default constructor>. При использовании этого стиля неизменяемые ячейки ведут себя, как должны вести себя плейсхолдеры. Курсор можно поместить только на первый символ, изменить значение невозможно. Допускаются только изменения, предусмотренные доступным в этом месте меню трансформации.

Логический параметр doNotCompile модулей языка сборки был заменен на перечисление Java. Это позволяет лучше различать следующие случаи:

• Модуль вообще не содержит кода.
• Модуль содержит код, но этот код компилируется с помощью других инструментов, а не MPS.

Раньше в обоих этих случаях параметр принимал значение true.

Новое перечисление Java содержит три возможных значения:

• compile in MPS
• compile externally
• no code

При переходе на версию 2024.1 первоначальное значение false параметра doNotCompile будет изменено на compile in MPS, а значение true параметра doNotCompile — на compile externally.

Небольшая новая экспериментальная функция позволяет добавить ветвление к плану генерации, не меняя исходный план. План генерации можно отметить как ветвление другого плана. Помеченный таким образом план будет обрабатываться, как если бы на него была явно сделана ссылка со стандартной инструкцией fork в самом начале исходного плана генерации.

Кроме того, при определении ветвления можно использовать модификатор строки, служащий триггером. Ветвление произойдет, только если владельцем генерируемой модели является модуль, у которого идентификатор фасета цели генерации соответствует триггеру.

Тесты JUnit в MPS теперь могут создавать отчеты не только в форматах Vintage и Jupiter, но и в формате Open Test Reporting. Новая возможность доступна в параметрах тестирования языка сборки и позволяет сгенерировать отчет в формате Open Test. Если параметр имеет значение true, в директории проекта создаются файлы отчета с именем junit-platform-events*-$BUILD_NAME$.xml.

Если параметр имеет значение false, создаются, как и раньше, отчеты для движков Vintage и Jupiter.

Теперь в отчетах MPS о тестировании соблюдается аннотация JUnit @DisplayName, и имя добавляется в отчеты, показанные в окне отчетов о тестировании.