Edit–>Find–>Find Text in Project action (Ctrl-Alt-Shift-F) let you look up nodes with property values matching specified text. [MPS-4577]
An option to send Make process into background, available in MPS for years, hasn't been quite useful due to issues in MPS threading model. We have been working to improve UI responsiveness during background make, which got better now. Therefore, the setting to run make in background is preserved, so that once you've opted to send Make to background, all subsequent Make processes start in background right away. There's a new UI setting to control this, Preferences–>Project Settings–>Make/Perform in background, in case you'd like to restore old behavior. [MPS-13440] and [MPS-30037]
We employ IDEA's spellchecking mechanism to help you keep your BL comments clean and accurate. [MPS-8630]
One of the common use cases of test language is checking some node for error messages. One can want to check either that the node has no error messages, or that is has no error messages except those which are expected to appear or that some error message does in fact appear onto some node. Warnings also might need to be included into these checks. Due to some issues, MPS testing subsystem sometimes could not distinguish different errors appearing onto the same node. It could lead to some tests still passing despite of several messages was shown on a node instead of only single expected. Now testing subsystem becomes more rigorous, so you can face a situation where a test that used to pass with previous MPS releases becomes failing. You might want to review such tests and either avoid superfluous messages or add test annotation mentioning additional message
Checking rule is defined for some concept. It means that this rule is called for every node that is an instance of that concept. Previously, there was an option also to define checking rule for some pattern using pattern language. This option could be used for two reasons: narrowing rule applicability condition (compared with rules defined for pure concept) and convenient naming of properties, children, grandchildren etc. Both goals can be achieved by using pattern language inside a rule's body, in particular, using matches statement on top of its do block:
Checking rules having patterns in their body will not be supported in the future, so it is recommended to review them and move pattern into the rule body using the dedicated intention.
Checking rule defined for some concept is by default inherited by any of its subconcepts. So, checking some node includes executing all rules defined for the concept of the node and all its superconcepts. For special cases where one needs to avoid such inheritance there is overrides option in checking rule. In previous MPS versions, this option could take just two states: true or false, which were interpreted as overriding any rule defined for any superconcept, and as absence of overriding correspondingly. Now instead of overriding any rule inherited from superconcept you can explicitly specify the list of rules you want to override. It is strongly recommended to review all your checking rules that use overrides feature and to determine which of rules should be overridden.
Structure language provided option to create properties of a predefined set of values by declaring enumeration data type. Such enumerations were inconvenient to use and error-prone.
With this release, we refine enumeration declarations. New declarations provide a concise way to declare a list of options: each option is expressed with named enumeration member. Optionally you can alter the editor's presentation for some member and choose the default member, that is used when no member explicitly set in a property.
SModel language also refined experience working with enum properties: now property reads and writes work with typed enum-member instances instead of raw primitive values, that helps language designer to write code with fewer errors.
Additionally, we reworked all operations that work with enums.
Furthermore, SModel language now ships 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.
There were requests for the possibility to customize some of MPS error messages (https://youtrack.jetbrains.net/issue/MPS-9668, https://youtrack.jetbrains.net/issue/MPS-23408)
As of this release, all the constraints error reporting could be modified.
We are planning to make the customization of reporting for other kinds of errors available in the next releases.
New aspect named 'feedback' is available for the purpose of error text customization.
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 edges or vertices
in the diagram editor.
As for 2019.2, only the default feedback 'ShowMessage' is available in MPS.
The feedback 'ShowMessage' defines the text you see in the tooltip when you move the mouse cursor over the node with the problem.
In order to modify the messages for the failing canBeChild, canBeParent, canBeAncestor, canBeRoot constraints functions you can use
the new constraints-rules languages (see below).
Just create a new root of the concept 'RulesConstraintsRoot' in the model 'constraints' of your language.
In this root you can describe the logic which is usually given in the constraints root in the canBe* functions.
The new language for describing constraints is more declarative and supposed to simplify the life of language designer by encouraging to write simpler and more modular
rules instead of java-like concept functions which are also still available in the root ConceptConstraints.
So far, the new root RuleConstraintsRoot does not allow to define scopes and property constraints, so this functionality needs to be considered as experimental.
Until there is a proper replacement for scopes and properties in the language, the root ConceptConstraints will be the legal way to define constraints in your language.
As of this release, the new facade API is the only supported way to run typechecking queries.
See jetbrains.mps.typechecking.TypecheckingFacade and related classes.
The hierarchy of 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 "typesystem" aspect.
The following is a tentative plan of changes to be made in relation to typesystem support. This is subject to discussion.
The aspect that has been responsible for implementation of typesystem and the language used in this aspect will become legacy. With time the language and the runtime support will migrate 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 is a total rewrite of the legacy engine.
[MPS-9402] MPS 2019.2 comes with an action to show VCS history of changes to a specific root. Selection history functionality, well-known from IDEA IDEs, is limited in MPS to a whole root node at the moment. The action is available from editor's context menu:
Note, collecting root history, as almost any other VCS history action, is time-consuming. There's progress indicator in status bar that helps to bear with this.
The dialog is similar to Selection History dialog of an IDEA IDE:
List of revisions in the dialog shows revisions of a model file when respective root has been changed.
Since 2019.2, MPS is run under JDK 11. This affects mechanisms of loading stub models.
Typically, there's nothing to migrate, though some JDK classes and fields were moved. Still, these cases are quite rare.
In Idea plugin, module with MPS facet should now have JDK at least of version 11. Otherwise, it will not generate.
TODO Mihail Muhin