Nouveautés de MPS 2019.2
Type de données énumération
Les nouvelles déclarations des types de données Enumeration fournissent un moyen concis de déclarer une liste d'options : chaque option est exprimée par un membre nommé de l'énumération. Il est également possible d'altérer la présentation de l'éditeur pour certains membres et de choisir le membre par défaut à utiliser si aucun membre n'est défini explicitement dans une propriété.
Personnalisation des messages d'erreur Sponsorisé par un de nos clients
Pendant quelques temps, nous avons reçu des demandes de clients souhaitant personnaliser certains messages d'erreur de MPS. Grâce à une requête formulée par l'un de nos clients payants, nous avons pu accorder une priorité élevée à cette fonctionnalité. Désormais, tous les critères du reporting des erreurs peuvent être modifiés. Nous prévoyons de généraliser cette personnalisation du reporting à d'autres types d'erreurs dans les prochaines versions.
Un nouvel aspect appelé "Feedback" est disponible pour la personnalisation du texte des erreurs.
Langage de contraintes basées sur des règles
Le langage de contraintes basées sur des règles a été créé afin de remplacer à terme la contrainte canBe* actuellement disponible, qui provient du langage de contraintes MPS standard. Nous considérons le langage de contraintes basées sur des règles comme une fonctionnalité expérimentale, et elle devrait donc évoluer considérablement dans les prochaines versions.
Historique de la racine
Le menu Git comprend une nouvelle action permettant d'afficher l'historique des modifications VCS à une racine donnée. L'action est disponible dans le menu contextuel de l'éditeur.
Recherche en texte intégral
La recherche en texte intégral dans les valeurs de propriétés est disponible. L'action Modifier->Rechercher->Rechercher du texte dans le projet (Ctrl+Alt+Maj+F) vous permet de rechercher des nœuds comportant des valeurs de propriété correspondant au texte spécifié.
Vérification d'erreur spécifique
L'un des cas d'utilisation courant d'un langage de test consiste à vérifier si les nœuds comportent des messages d'erreur ou des avertissements. Le sous-système de test de MPS n'était parfois pas en mesure de distinguer entre les différentes erreurs apparaissant sur le même nœud. Cela pouvait entraîner un comportement trompeur : même si l'utilisateur précise l'erreur attendue à l'intérieur de l'annotation de test correspondante, tout(e) autre erreur ou avertissement signalé(e) à ce nœud n'apparaîtrait pas en tant que violation du test.
Vérification des règles définies pour les schémas
Lors de la définition d'une règle de vérification pour un concept, la règle est ensuite appelée pour tous les nœuds constituant une instance du concept.
Désormais, au lieu d'écraser toutes les règles héritées du superconcept, il est possible de spécifier la liste des règles à écraser de façon explicite. Nous recommandons fortement de passer en revue toutes vos règles de vérification qui utilisent cette fonctionnalité d'écrasement, et de déterminer quelles règles doivent être remplacées.
API Façade pour la vérification de type
À compter de cette version, la nouvelle API Façade est le seul moyen pris en charge pour lancer des requêtes de vérification de type.
Nouvelle API : reportez-vous à jetbrains.mps.typechecking.TypecheckingFacade et aux classes associées.
Ancienne API (obsolète) : La hiérarchie des packages jetbrains.mps.typesystem.* est désormais obsolète. Toute utilisation directe des classes au sein de cette hiérarchie est déconseillée, sauf pour le code qui est automatiquement généré à partir du contenu d'un aspect "typesystem".
Modifications prévues dans les prochaines versions
Vous trouverez ci-après un plan des modifications restant à apporter en ce qui concerne la prise en charge du système de type. L'aspect chargé de l'implémentation du système de typage et le langage utilisé dans cet aspect deviendront obsolètes. Au fil du temps, la prise en charge du langage et de l'exécution sera exportée vers une extension distincte.
Un nouvel aspect à venir remplacera la partie "non typesystem" de l'aspect typesystem. Une migration sera mise à disposition pour extraire les règles de vérification de l'ancien aspect typesystem.
Une nouvelle prise en charge du framework et de l'exécution du contrôle du typage sera fournie, ce qui implique une réécriture totale de l'ancien moteur.
Make en arrière-plan
Les processus Make fonctionnent correctement en arrière-plan. Nous avons cherché à améliorer la réactivité de l'interface utilisateur pendant l'exécution de ce processus en arrière-plan. Pour restaurer la version précédente, vous trouverez un nouveau paramètre de l'interface utilisateur permettant de contrôler tout cela (Preferences–>Project Settings–>Perform in background).
Java 11 en tant qu'environnement d'exécution
MPS fonctionne désormais sous JDK 11. Cela affectera le mécanisme du chargement des modèles de stub. La plupart du projet ne nécessitera pas de migration, à l'exception des rares utilisations de certaines classes et de certains champs repackagés dans JDK 11.
Dans l'extention IntelliJ IDEA, les modules avec une facette MPS doivent maintenant être associé à JDK version 11. Sans cela, la génération de code échouera.
BaseLanguage
Les améliorations de BaseLanguage ont été l'un des principaux objectifs de cette version. Nous avons corrigé beaucoup d'erreurs associées aux BaseLanguages, allant des bogues aux problèmes de convivialité.
Nouvel exemple
Grâce aux commentaires de la communauté, nous avons ajouté un nouvel exemple de projet pour la génération XML.
Vérification orthographique dans les commentaires de BL
Nous proposons une vérification orthographique pour les commentaires d'une ligne, le texte de Javadoc et les littéraux de chaîne.
Configuration git locale
Nous avons modifié les paramètres du moteur de fusion (de global à local, par dépôt git). Il est donc maintenant possible d'avoir autant de moteurs de fusion que d'installations MPS.