Dans un projet Kotlin standard, vous pouvez utiliser des ensembles de sources pour séparer le code ciblant différentes plateformes. Dans MPS, nous avons introduit cela au niveau racine, avec la possibilité de spécifier l'ensemble des plateformes prises en charge pour chaque nœud racine Kotlin. Vous pouvez configurer ces ensembles de sources au niveau du nœud racine à l'aide d'une action d'intention.

En voici les implications pratiques :

• Le code sous un ensemble de sources donné ne peut accéder qu'aux déclarations avec des plateformes compatibles. Par exemple, le code spécifique à la JVM peut accéder uniquement au code spécifique à la JVM et au code commun qui cible la JVM.
• Les sources générées sont structurées dans des répertoires spécifiques à l'ensemble de sources. Si un répertoire n'est pas spécifié, il utilise l'ensemble de sources par défaut, qui correspond à la valeur par défaut du module.
• Les déclarations expect et actual sont désormais prises en charge.

Par défaut, le code Kotlin sans plateforme explicite utilise la JVM, afin de maintenir la rétrocompatibilité.

Le code Kotlin dans MPS générait de nombreuses erreurs de typesystem et de portée lorsque le plugin Kotlin Typesystem, basé sur CodeRules, n'était pas disponible. Afin d'améliorer la lisibilité et la testabilité, ces vérifications et erreurs sont désormais désactivées lorsque le plugin du système de types basé sur CodeRules n'est pas disponible.

Dans de tels cas, toutes les portées des langages Kotlin sont remplacées par une portée par défaut incluant tous les nœuds des concepts compatibles. Cela supprime toutes les erreurs de faux positifs, car tous les nœuds valides sont dans la portée.

Les directives pour gérer le code Kotlin restent les mêmes qu'auparavant :

• Pour l'écriture et la vérification du code Kotlin, CodeRules doit être activé et le plugin Kotlin Typesystem doit être installé.
• La lecture de Kotlin et sa génération peuvent s'effectuer en toute sécurité sans eux.

Le volet Logical View s'appuie désormais sur une architecture asynchrone, ce qui permet de maintenir la réactivité de l'interface utilisateur et améliore les performances globales de l'IDE. La nouvelle implémentation facilite également les extensions et les modifications. Pour en savoir plus, reportez-vous à notre article intitulé ProjectPane implementation on top of ProjectViewTree (Implémentation de ProjectPane par-dessus ProjectViewTree) dans la base de connaissances.

Cette nouvelle implémentation a entraîné quelques changements notables :

• Les indicateurs d'erreur et d'avertissement ne sont plus disponibles.
• Les erreurs et les avertissements trouvés dans la hiérarchie sont soulignés en rouge.
• L'option Show Descriptor Models affecte tous les modèles de descripteur.
• Certaines opérations de glisser-déposer fonctionnent différemment.
• Les paramètres du volet Logical View ont été légèrement réorganisés.

Nous avons introduit un nouveau style dans BaseLanguage qui permet aux cellules constantes de servir d'espaces réservés s'il manque une valeur (un nœud enfant ou une référence). Par exemple, si une classe ne comporte aucun constructeur, une cellule d'espace réservé <no default constructor> peut être affichée à la place. Le style amène les cellules constantes à présenter le comportement que vous attendez de ces cellules d'espace réservé. Le curseur ne peut être placé qu'à la première position et il n'est pas possible de modifier la valeur. Seules les modifications fournies par les menus de transformation associés sont autorisées.

L'option booléenne doNotCompile des modules dans le langage de build a été remplacée par une énumération Java pour mieux distinguer les cas où :

• Le module ne contient aucun code.
• Le module contient du code, mais le code est compilé par des outils autres que MPS.

Ces deux cas étaient représentés par la valeur true.

La nouvelle enum Java a trois valeurs possibles :

• compile in MPS
• compile externally
• no code

Lors de la migration vers la version 2024.1, la valeur false d'origine de doNotCompile sera migrée vers compile in MPS, tandis que la valeur true de doNotCompile sera migrée vers compile externally.

Une nouvelle petite fonctionnalité expérimentale vous permet d'ajouter un fork pour un plan de génération sans réellement modifier le plan d'origine forké. Vous pouvez indiquer qu'un plan de génération est forké à partir d'un autre plan de génération. Le plan que vous aurez signalé sera traité comme s'il était mentionné explicitement, avec l'instruction standard fork insérée au tout début du plan de génération forké.

De plus, lors de la définition d'un fork, vous pouvez utiliser un modificateur de chaîne qui servira de déclencheur. Le fork ne se produira que si le modèle généré appartient à un module dont la facette cible de génération possède un identifiant de facette correspondant au déclencheur de chaîne.

Les tests JUnit dans MPS peuvent désormais générer des rapports de test non seulement aux formats Vintage et Jupiter, mais également au format Open Test Reporting. Une nouvelle option est disponible dans les options de test du langage de build pour contrôler si le rapport Open Test est inclus dans les rapports générés. Si l'option est définie sur true, des fichiers de rapport, nommés junit-platform-events*-$BUILD_NAME$.xml, sont créés dans le répertoire du projet.

Si l'option est définie sur false, ce sont les anciens rapports pour les moteurs Vintage et Jupiter qui sont créés.

Les rapports de test MPS respectent désormais l'annotation JUnit @DisplayName et propagent le nom aux rapports affichés dans la fenêtre d'outil du rapport de test.