Now after applying changes from one side of the conflict the other conflicting changes are converted to the addition into the end of the changed group and it is possible necessary to apply or ignore them separately.
Image RemovedImage Added
Fixed and improved actions for working with deprecated code
Both introduced generation-time concepts have described in this article.
Default methods support in BaseLanguage
In the new version MPS allows to create the 'default' methods in BaseLanguage interfaces.
The 'default' keyword is implemented by the DefaultModifier concept which extends the Modifier concept in the BaseLanguage. DefaultModifier is located in the jetbrains.mps.baseLanguage.jdk8 language, which means that in order to create a 'default' method in the interface, one needs to import the jdk8 language.
The transformation/substitute menu + some cosy intentions are also supplied.
Image AddedImage Added
Concept overridden/implemented icons
MPS marks concepts with an overridden/implemented icons, allowing user to navigate to the superconcept or subconcept of the current concept.
Overridden/implemented icons further enhancements
The popups with the overridden/implemented concepts/classses/methods became asynchronous, which means that MPS fills the popup with the search results in background. During this activity one might navigate to some occurrence which has been already located by the MPS search engine.
Also the filtering by the name of search objects is available now.
Also the finders distributed by MPS got updated and optimized.
Furthermore, in order to execute a finder asynchronously one needs to use a special OnEachNodeFoundByExpression, which represents a simple finder invocation with a callback which is executed for each found node.
Consequently the find usages options for a concept have been changed.
The options have been extended with Derived Concepts and Concept Ancestors, which yield the list of subconcepts and superconcepts, respectively.
Also the find usages options for the behavior methods have been extended with "Overridden Methods" and "Overriding Methods".
Suppressing specific errors
Error suppressing used to be a rough tool to prevent MPS from showing error improperly found by typesystem checker. If a node was annotated with attribute 'SuppressErrorAnnotation' using intention 'Suppress error for node ...', no error message was shown for that node and all of its descendants. Now there is a possibility to suppress only specific error messages.
The selected error message will be suppressed for the node and all its descendants while other messages remain present. For more information see the documentation page.
Saving migration data as annotations
Migration scripts communicate with each other using migration data, special fragments of AST which are produced by some migration script and consumed by another one. In previous MPS versions, these data fragments were stored in special files laying somewhere nearby the module descriptor. This approach had the main disadvantage that such files with migration data cannot be merged easily if modified in two branches simultaneously. Now MPS supports another mechanism of transferring migration data which is highly recommended for newly created migrations. Produced node containing data should be now attached to any node that is close enough to the place to which the data is related. If there is no specific place to put annotation because it is related to the whole model, data node will be attached as a new root in current model.
Migration script producing nodes with data should declare the concept of such nodes and use putData() construction to insert each of such annotations into the model:
Retrieving nodes containing data performs quite the similar way as it used to be:
BuildMps_IdeaPlugin packaging option
The custom packaging option in the BuildMps_IdeaPlugin (the idea plugin declaration) got deprecated and should not be used from now on.
Instead one has to choose now the possible layout packaging right in the layout BuildMpsLayout_Plugin construction.
There are two possible options for now. One is auto packaging, that behavior corresponds to the absent "custom packaging" flag in the 2018.2 version, meaning
that all the provided languages and solutions are put into the 'languages' folder under the plugin root directory.
The second corresponds to the present 'custom packaging' options at all of the items listed in the BuildMps_IdeaPlugin declaration in MPS 2018.2.
It implies that the developer has to provide the whole plugin layout on his own.