En un proyecto de Kotlin normal, puede utilizar conjuntos de fuentes para separar el código destinado a diferentes plataformas. En MPS, hemos introducido esto en el nivel raíz, con la opción de especificar el conjunto de plataformas compatibles para cada nodo raíz de Kotlin. Estos conjuntos de fuentes pueden configurarse a nivel de nodo raíz con la ayuda de una acción de intención.

En la práctica, esto significa que:

• El código bajo un determinado conjunto de fuentes solo puede acceder a declaraciones con plataformas compatibles. Por ejemplo, el código específico de la JVM solo puede acceder al código específico de la JVM y al código común dirigido a la JVM.
• Las fuentes generadas están estructuradas en directorios específicos del conjunto de fuentes. Si no se especifica un directorio, se utiliza el conjunto de fuentes predeterminado, que corresponde al predeterminado del módulo.
• Ahora se admiten declaraciones esperadas y reales.

De forma predeterminada, el código de Kotlin sin una plataforma explícita utiliza la JVM, con el fin de mantener la compatibilidad con las versiones anteriores.

El código de Kotlin en MPS generaba muchos errores de ámbito y typesystem cuando el complemento Typesystem de Kotlin, basado en CodeRules, no estaba disponible. Para mejorar la legibilidad y la capacidad de pruebas, estas comprobaciones y errores se silencian ahora cuando el complemento typesystem basado en CodeRules no está disponible.

En dichos casos, todos los ámbitos de los lenguajes de Kotlin se sustituyen por un ámbito predeterminado que incluye todos los nodos de conceptos compatibles. Esto elimina cualquier error de falso positivo, dado que todos los nodos válidos se encuentran en el ámbito.

Las pautas para trabajar con el código de Kotlin siguen siendo las mismas que antes:

• Escribir y comprobar código de Kotlin debe hacerse con CodeRules activado y el complemento Typesystem de Kotlin instalado.
• La lectura de Kotlin y su generación pueden realizarse con seguridad sin ellos.

El panel Logical View se basa ahora en una arquitectura asíncrona, que ayuda a mantener la respuesta de la interfaz de usuario y contribuye al rendimiento general del IDE. La nueva implementación también permite extensiones y modificaciones más sencillas. Para obtener más información, consulte nuestro artículo en la base de conocimientos titulado ProjectPane implementation on top of ProjectViewTree.

Esta nueva implementación ha dado lugar a algunos cambios destacables:

• Los indicadores de error y advertencia ya no están disponibles.
• Tanto los errores como las advertencias encontrados en la jerarquía aparecen subrayados en rojo.
• La opción Show Descriptor Models afecta a todos los modelos de descriptores.
• Algunas operaciones de arrastrar y soltar funcionan de forma diferente.
• Los ajustes del panel Logical View se han reorganizado parcialmente.

Hemos introducido un nuevo estilo en BaseLanguage que permite que las celdas constantes sirvan como marcadores de posición si falta algún valor (un nodo secundario o una referencia). Por ejemplo, cuando no hay ningún constructor presente en una clase, se puede mostrar una celda de marcador de posición <no default constructor> en su lugar. El estilo hace que las celdas constantes muestren el comportamiento que cabría esperar de dichas celdas de marcador de posición. El cursor solo puede situarse en la primera posición y no es posible modificar el valor. Solo se permiten las modificaciones proporcionadas por los menús de transformación adjuntos.

La opción booleana doNotCompile de los módulos en el lenguaje de compilación se ha sustituido por una enumeración de Java para distinguir mejor los casos en que:

• El módulo no contiene código en absoluto.
• El módulo contiene código, pero el código se compila con herramientas que no sean MPS.

Ambos casos estaban representados por el valor true.

La nueva enumeración de Java tiene tres valores posibles:

• compile in MPS
• compile externally
• no code

Al migrar a la versión 2024.1, el valor original false de doNotCompile se migrará a compile in MPS, mientras que el valor true de doNotCompile se migrará a compile externally.

Una nueva y pequeña funcionalidad experimental permite añadir una bifurcación a un plan de generación sin modificar el plan original que se está bifurcando. Un plan de generación puede marcarse como bifurcación de otro plan de generación. El plan marcado se tratará como si se hiciera referencia a él explícitamente con la instrucción fork estándar insertada al principio del plan de generación bifurcado.

Además, al definir una bifurcación, puede utilizar un modificador de cadena que servirá como desencadenante. La bifurcación solo se producirá si el modelo que se está generando pertenece a un módulo que tenga una faceta de destino de generación con un ID de faceta que coincida con el desencadenante de cadena.

Las pruebas de JUnit en MPS ahora pueden generar informes de pruebas no solo en los formatos de Vintage y Jupiter, sino también en el formato de Open Test Reporting. Hay una nueva opción disponible en las opciones de prueba del lenguaje de compilación para controlar si el informe de Open Test se incluye en los informes generados. Si la opción está configurada con el valor true, se crearán archivos de informe llamados junit-platform-events*-$BUILD_NAME$.xml en el directorio del proyecto.

Si la opción está configurada con el valor false, se crean los informes heredados para los motores de Vintage y Jupiter.

Los informes de prueba de MPS ahora respetan la anotación @DisplayName de JUnit y propagan el nombre a los informes que se muestran en la ventana de herramientas de informes de prueba.