Download MPS 2019.2
Enumerated Data Types
A new way to declare enumerated data types allows you to define a list of options in a compact form by specifying a named value for each option. If necessary, you can configure the way some values are displayed or select the default value that will be used if the property has not been explicitly set to any value.
We have also improved aspects of the SModel language regarding working with properties of enumerated types. Now, when reading and writing properties, typed instances of enumerated members are used instead of the initial elementary values, which helps developers write code with fewer errors.
In addition, we redesigned all operations that are performed with enumerated types.
An Enum Switch statement has been added to the SModel language for multiple selection of enumeration members. It can also be used as an expression to calculate various values depending on which member of the enumeration satisfies the requirements.
Customizing Error Messages
For quite some time now, we have received requests to implement the ability to configure some error messages in MPS. Due to a request from one of our commercial customers, we were able to give this functionality the highest priority. Now you can configure all error messages related to checking constraints. In future versions, we are going to make these customization options available for other types of errors.
In this version, we have added a new aspect of the language called feedback. You can use this aspect to customize the text of error messages related to checking the structure, property restrictions, and scope.
For example, ShowMessage defines the text that appears in the tooltip that appears when you hover over a problem node.
Please note: you can set your feedback by expanding the provided set of feedback languages. For example, you can describe feedback, which will highlight edges or vertices in the chart editor.
To receive custom error messages for canBe * restrictions, use the rule-based restriction language.
Rule Based Constraint Language
We have created a rule-based constraint language that in the future will replace the currently available canBe * constraint from the standard MPS constraint language. Currently, the rule-based constraint language is experimental functionality, so it is likely to change a lot in future releases.
At the moment, the previous version of restrictions remains a priority, therefore, to introduce restrictions based on rules, the old canBe * restrictions must be completely removed. The new language for determining constraints is more declarative; it requires a set of isolated constraints (rules) to be specified instead of one conditional block.
In version 2019.2, this allows you to receive an individual error message for each rule individually.
Root history
There is now a new action in the Git menu that allows you to display the history of changes in VCS for a specific root. The action is available from the editor’s context menu:
Note that collecting root history data, like any other history related VCS action, is time consuming. There is a progress bar in the status bar to help you evaluate the time spent.
The dialog box is similar to the Selection History dialog in IntelliJ IDEA:
A dialog box displays a list of revisions of the model file in which the corresponding root has been changed.
Data Search
A full-text search on property values is now available. The action Edit–> Find–> Find Text in Project action (Ctrl + Alt + Shift + F) allows you to find nodes with properties whose values contain the specified text.
Check for specific errors
One common use case for writing a test language is checking the nodes for error messages and warnings. In some cases, the MPS testing subsystem did not distinguish between different types of errors affecting the same node. This could lead to confusion: even if the user explicitly indicated the expected type of error in the test annotation, other errors and warnings affecting the corresponding node did not generate test errors.
Keep in mind that when upgrading to a new version, some tests may fail, because now they will only suppress warnings and errors that the user indicates in the annotation for verification.
Patterns in definitions of validation rules
If you define a validation rule for a concept, it will be called for each node that is an instance of that concept.
Now, instead of overriding each rule inherited from the parent concept, you can explicitly specify a list of rules that need to be redefined. We strongly recommend that you review all of your validation rules using the overrides function and indicate which rules should be redefined.
Previously, you could define a validation rule for a concept using a template language. This feature served to limit the conditions of applicability of the rule (compared with rules defined exclusively for the concept), as well as for convenient naming of properties, children and grandchildren, etc. For both purposes, the use of the template language inside the body of the rule is suitable, in particular, the use of the match operator at the top of the do block:
In the future, we do not plan to support validation rules with templates in the headers, so we recommend that you find such cases and move the templates to the body of the rule using a special action.
Java 11 as runtime
MPS will now run in JDK 11. This will affect the loading mechanism of stub models. Most of your project will not need to be migrated, except in the rare cases where some classes and fields have been repackaged in JDK 11.
When using the plugin for IntelliJ IDEA, modules with MPS Facet should now be associated with JDK version 11. Otherwise, code generation will fail.
Type Facade API Facade
Now, type checking requests can only be performed using the new API facade.
New API: see jetbrains.mps.typechecking.TypecheckingFacade and related classes.
Deprecated API: jetbrains.mps.typesystem. * Package hierarchy is now deprecated. Using classes from this hierarchy is not recommended, with the exception of code that is automatically generated from the contents of the typesystem aspect.
Planned changes in future releases
Here is a preliminary outline of changes affecting type system support:
- The aspect responsible for implementing the type system and the language used in it will be deprecated. Over time, the language and its support in the runtime will be moved to a separate plugin.
- A new aspect will be added that will effectively replace the non-type system part of the typesystem aspect. Migration will be provided to extract validation rules from the old aspect of typesystem.
- A new type checking framework will be implemented with support from the runtime, as a result of which obsolete mechanisms will be rewritten from scratch.
Assembly in the background
We increased the responsiveness of the interface during the background build. If the build process was sent to the background once, it will always be performed in the background during subsequent executions. The action is saved in the menu Preferences-> Project Settings-> Perform in background.
Base language
One of the main goals of this release was to improve BaseLanguage. We fixed a number of issues affecting BaseLanguage languages, starting with bugs and ending with usability issues.
Spell check in BL comments
Spell checking is now available for single-line comments, Javadoc text, and string literals.
New sample project
We took into account the wishes of the community and added a new sample project with XML generation.
Local Git Configuration
Now the settings of the merge driver are not global, but local (separate for each Git repository), so each installed copy of MPS can have its own merge driver.
You can download this version here , we hope you enjoy it. Please report any problems to us in our tracker .
Your JetBrains MPS Team
The drive to develop