Child pages
  • What's new in MPS 2018.3 (draft)

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


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.

For example:

Image RemovedImage Added
After applying left version of the conflict you still can apply or ignore the line from the right side:

Image RemovedImage Added

Fixed and improved actions for working with deprecated code


  • First option just add all MPS tips to final distribution. This is default option for build script generated with wizard.
  • Second one required manually created folder with correct structure of tips and IdeTipsAndTricks.xml - correct structure can that can be obtained from mps-tips.jar itself. You need folder that contains html files, css and images folders.
  • Last option allows to use and jetbrains.mps.core.xml languages to quickly create basic tips in MPS itself.


Importing from solution to build script tips & tricks by pointing to solution and generated xml from MPSTipsAndTricks concept:

Fully compiled datatypes

Moving forward to fully compiled languages we've made datatypes to be completely generated. All generated information regarding datatypes is now available from SModel API.

New generation facilities for BaseLanguage extensions

BaseLanguage is intended to be customized with lots of extensions. However, for some extensions, it is tricky to implement proper generator especially when you have to consider that there are some other independent extensions can be instantiated in a model. Now BaseLanguage provides new several generation-time concepts to make writing extensions' generators easier for some cases.

Generating of lvalue-expressions. Lvalue expressions are such expressions that are evaluated to variables which can be read or written with some value. For some cases generation of lvalue-expression become hard since it might depend on in what context the expression is used. Now new `generic lvalue-expression` generation-time concept can be utilized to make a generator simpler and context-unaware.

Image Added

Transform lvalues to references. Some expressions aggregate other lvalue-expressions to make compound operations with a variable that is produced from aggregated expression (e.g. plus assignment or increment and get expressions). Introducing new expressions with such semantics had been unfeasible since it is hard to write a proper generator for such constructions. Fortunately, in new release you can wrap arbitrary lvalue-expression with `@byRef` expression so then baseLanguage generator will transform wrapped expression into expression of type `Reference<T>` that provides get and set operations over a wrapped variable.

Image Added

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.

Image Added

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.

Image Added

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.

Image Added

Finder changes

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.

Image Added

Consequently the find usages options for a concept have been changed.

Image Added

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".

Image Added

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.

Image Added

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:

Image Added

Retrieving nodes containing data performs quite the similar way as it used to be:

Image Added

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.

Image Added

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.

Image Added

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.

Image Added