The third Early Access Program for MPS 2019.2 is waiting for you
The MPS 2019.2 EAP3 comes with new functionality and gives shape to the final release.
Enumeration data type
New 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.
SModel also ships a statement for switching on enum members. It also can be used as an expression to evaluate different values depending on what enum member is met.
Local git configuration
We’ve changed merge driver settings from global to local (per git repository), so now it is possible to have as many merge drivers as MPS installations.
Specific error checking
One of the common use cases of test language is checking some node for error messages or warnings. The testing subsystem of MPS sometimes could not distinguish different errors appearing on the same node. This could lead to misleading behavior: even if user specifies expected error inside 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 body 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.
Not only that, this EAP build fixes several annoying bugs reported by our community.
Have a nice day!
Your JetBrains MPS Team
The Drive to Develop
Subscribe to MPS Blog updates
