MPS 2019.2: Enumerations data type, Error messaging customization, Root history, Migration to JDK 11, and much more.
The final release is here. This version brings us a lot of new functionality to different subsystems and a long list of fixed bugs.
Enumeration data types
New Enumeration data type declarations provide a concise way to declare a list of options: each option is expressed with a named enumeration member. Optionally, you can 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.
The SModel language has also refined the experience of working with enum properties. Now property reads and writes work with typed enum-member instances instead of raw primitive values, which helps language designers write code with fewer errors.
Additionally, we reworked all operations that work with enums.
Enum Switch statement was added to SModel language, providing the possibility for switching on enum members. It can also be used as an expression to evaluate different values depending on what enum member is met.
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. All constraint checker error messages can be customised now.
We are planning to make this reporting customization available for other kinds of errors in the next releases.
New language aspect named ‘feedback’ was added in this version. This aspect can be used for customising the text of error messages reported by structure validation, property and scoping constraints.
The feedback ‘ShowMessage’ defines the text displayed in the tooltip when you move the mouse cursor over the problem node.
Note that you can define your own custom feedback by extending the given set of feedback languages, for instance, you might describe a feedback which highlights the edges or vertices in the diagram editor.
In order to provide custom error messages for canBe* constraints, use the rule-based constraints language.
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.
For now we keep precedence of old-style constraints, so old canBe* constraints should be completely removed in order to let rule-based constraints step in. New constraints definition language is more declarative, it forces the language designer to specify a set of isolated constraints (rules) instead of the single conditional block.
In 2019.2 it allows to provide a custom error message for each rule individually.
Root History
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:
Note, collecting the root history, as with almost every other VCS history action, is time-consuming. There’s a progress indicator in status bar that helps you bear with this.
The dialog is similar to the Selection History dialog in IntelliJ IDEA:
A list of revisions in the dialog shows revisions of a model file when the respective root has been changed.
Full-text search
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.
Keep in mind that migrating to the new version might cause some tests to fail because now they are only suppressing the warnings and errors that the user specified in the error checking annotation.
Checking rules defined for patterns
When you define 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, you can explicitly specify the list of rules you want to override. We strongly recommend that you review all your checking rules that use the overrides feature, and determine which rules should be overridden.
Previously, there was an option to define the checking rule for a concept using a pattern language. This option could be used for narrowing the rule applicability condition (compared with rules defined purely for a concept), and for convenient naming of properties, children, grandchildren, and so on. Both goals can be achieved by using a pattern language inside the rule body, in particular, by using the matches statement on top of its do block:
Checking rules with patterns in their headers will no longer be supported in the future, so we recommend that you review them and move the pattern into the rule body using the dedicated intention.
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.
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
We have been working to improve the UI responsiveness during the background make. If the make process was sent to the background once, it will always be performed in the background on subsequent executions. The action is saved in Preferences->Project Settings-> Perform in background.
BaseLanguage
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.
Spell-check in BL comments
We have spellcheck for single-line comments, Javadoc text, and string literals.
New Sample
Based on feedback from the community, we have added a new sample project for XML generation.
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.
And that’s it! We hope you enjoy this release and keep reporting everything you find to our issue tracker.
Have a nice day!
Your JetBrains MPS Team
The Drive to Develop
Subscribe to MPS Blog updates
