Enumeration data type
New Enumeration data types declarations provide a concise way to declare a list of options: each option is expressed with a named enumeration member. Optionally, it’s possible to alter the editor’s presentation for some members and choose the default member that is used when no member is explicitly set in a property. Learn more.
Customization of error messages
For some time, there were requests for the possibility to customize some MPS error messages. Thanks to a request from one of our paying clients, we were able to give a highest priority state to this feature. Now, all the constraints of error reporting can be modified. We are planning to make this reporting customization available for other kinds of errors in the next releases.
A new aspect named 'feedback' is available for error text customization. Learn more
Rule-based constraints language
Rule-based constraints language was created in order to replace currently available canBe* constraint from the regular MPS constraints language in the future. We consider Rule-based constraints language as experimental functionality, so we expect it to evolve significantly in next releases. Learn more.
The Git menu comes with a new action to show the history of VCS changes to a specific root. The action is available from the editor's context menu. Learn more
Full-text search in the property values is ready. Edit–>Find–>Find Text in Project action (Ctrl+Alt+Shift+F) lets you look up nodes with property values that match the specified text.
Specific error checking
One of the common use cases of a test language is to check nodes for error messages or warnings. The testing subsystem of MPS was sometimes not able to distinguish between different errors appearing on the same node. This could lead to misleading behavior: even if the user specifies the expected error inside the corresponding test annotation, any additional errors and warnings reported upon this node would not be reported as test violations. Learn more.
Checking rules defined for patterns
When defining a checking rule for a concept, the rule is then called for every node that is an instance of the concept.
Now, instead of overriding any rule inherited from the superconcept, the list of rules to override can explicitly be specified. We strongly recommend to review all your checking rules that use the overrides feature, and determine which rules should be overridden. Learn more
Typechecking Facade API
As of this release, the new facade API is the only supported way to run typechecking queries.
New API: See jetbrains.mps.typechecking.TypecheckingFacade and related classes.
Deprecated API (legacy): The hierarchy of the packages jetbrains.mps.typesystem.* is now deprecated. Any direct usage of classes within this hierarchy is discouraged, except for code that is automatically generated from the contents of a "typesystem" aspect.
Changes upcoming in the following releases
The following is a tentative plan of changes to be made in relation to typesystem support. The aspect that has been responsible for the implementation of typesystem and the language used in this aspect, will become legacy. With time the language and the runtime support will be migrated to a separate plugin.
A new aspect to be introduced that will essentially replace the "non-typesystem" part of typesystem aspect. A migration will be provided to extract checking rules from the legacy typesystem aspect.
A new typechecking framework and runtime support to be introduced, which means a total rewrite of the legacy engine.
Make in Background
Make processes in Backgrounds work properly. We have been working to improve the UI responsiveness during the background make. To restore the previous version, there’s a new UI setting to control all this, Preferences–>Project Settings–>Perform in background.
Java 11 as runtime
MPS will now run under JDK 11. This will affect the mechanism of loading stub models. Most of the project won’t need migration, except rare usages of some classes and fields repackaged in JDK 11.
In the IntelliJ IDEA plugin, the modules with MPS facet should now be associated with JDK version 11. Otherwise, code generation fails.
BaseLanguage improvements were one of the main goals for this release. We fixed a lot of issues related to BaseLanguages, from bugs all the way to usability problems.
Based on feedback from the community, we have added a new sample project for XML generation.
Spell-check in BL comments
We have spellcheck for single-line comments, Javadoc text, and string literals.
Local git configuration
We’ve changed the merge driver settings from global to local (per git repository), so now it is possible to have as many merge drivers as MPS installations.