MPS 2022.2 comes with annotations in inspector, improved Kotlin support, enhanced SModel API and much more.
Annotations are now accessible from the Inspector window, and the annotation process will start for the entire root. This action can be accessed by right-clicking on the left border of the Inspector window. The Annotation will open in both the Inspector editor and the main editor.
A lot of editing issues have been fixed to provide a better typing experience, such as:
T.() -> R
which was incorrectly loaded as
(T) -> R
).
it
parameter.
Receiver.() -> Unit
)
will properly use that receiver type as an implicit this
inside the body of the lambda.
SModel support is now available in MPS Kotlin with the new jetbrains.mps.kotlin.smodel language. Along with the enhanced compilation support, it allows for the usage of Kotlin code in language modules (as helper classes, for example).
On top of regular types (nodes, concepts, links, and references), it leverages the increased flexibility of MPS Kotlin to bring concept-type parameters. Functions, variables, and classes can now declare and use such parameters and reuse them in their internal types, which allows for easier typing and leverages Kotlin’s smart casts.
Kotlin compilation support has been improved with better persistence. As a result, Kotlin classes are no longer erased when MPS is restarted.
A new option has been added in build scripts to mark a module to be compiled with the Kotlin compiler. Insertion of this flag is manual – no automatic check is currently available to set it to true. The flag should be added when a module containing Kotlin files is going to be compiled to JVM.
When adding comments to BaseLanguage, it is now possible to customize them further with text style. Comments support bold (Ctrl + B), non-italics (Ctrl + I), underlined (Ctrl + U), and bold-non-italics styles (Ctrl + B -> Ctrl + I).
In BaseLanguage, it is now possible to do post-fix transformations that allow you to transform the code by appending some text to the expression. This saves developers time, as they do not have to move the caret to the front of the expression or select the expression in order to apply a transformation.
MPS used to discover models the moment they were registered with a repository. Discovering a model in a regular project module meant traversing the file system to find out files and their types, and reading at least the header information about the model.
Now, modules don’t engage in model discovery unless models are requested. There's a new SModule API (SModule.forEachRegisteredModel()) to access models already known to a module only, without triggering model discovery or loading. If you use SModel API clients, especially SRepositoryContentAdapter subclasses, you may want to adopt the new API to benefit from the improvement.
MPS now comes with a consistent API to create references, as well as an updated internal presentation. These changes aim to improve the model reference/persistence system, which is scheduled for later releases. Nevertheless, the change already allows you to reduce any model’s in-memory storage by approximately 5%.
MPS now respects versioned jar entries and would expose Java classes with a version that matches the actual Java runtime.
Although MPS and the IntelliJ Platform were using a stripped-down version of the Log4j library without known security issues, they have both switched logging to the standard java.util.logging package. A compatibility layer is implemented (based on SLF4J) to redirect requests from the Log4j API to a Java Util Logging (JUL) implementation.
The Debug Log Settings action allows you to configure DEBUG and TRACE levels for categories. Additionally, there is now also a bin/log.properties configuration file that uses the well-known JUL configuration format. Unlike log.xml from previous releases, this configuration file is not read by default, but users may request access to this (or any other external) configuration by using the idea.log.config.properties.file system property.
Ant build scripts that MPS generates from lang.build declarations use separate tasks to generate and compile sources (MPS-own <generate> and regular Ant <javac>). There’s now a new <mps.make> task that corresponds to the Make process launched from the IDE. It is responsible for the complete transition of a model down to compiled code. The task combines both code generation and compilation, which saves time as MPS needs compiled classes anyway for its module classloading purposes (as <javac> tasks often duplicate compilation efforts already completed during <generate>). It also makes Ant command-line builds and the Make process launched from the IDE much more similar to each other, thus increasing the reliability of your build process.
Generator tests have been improved with matching options that allow ignoring node ordering. There’s also a new action to reorder model roots, which helps to bring reference test models to the desired state.
MPS caps the time spent in the Model-to-Text (M2T) transformation part to address potential errors in TextGen aspects. The limit was previously hard-coded. However, lately some big models have been reaching the limit, causing an undesired timeout exception. So now, there’s an IDE setting that you can define to control the timeout. Support for command-line builds is planned for future releases.
MPS used to record dependencies between generated BaseLanguage classes in the `dependencies` file. The Java compiler relies on these to figure out whether dependent compilation classes need a refresh. But when ‘dependencies’ were changed in 2021.2 to hold higher-level dependencies, there was no longer a need to collect and store per-root class names. This helped MPS to improve TextGen time for both BaseLanguage code (as it no longer needs to collect individual dependencies) and the Java compile process (as it no longer needs to analyze individual file dependencies, attribute file dependencies to modules and classpath, and propagate ‘dirty’ state).
A new deps.cp file now stores per-module dependencies to let MPS deduce the module compilation graph. The file keeps the state of the transformation, which makes it ‘sealed’ and tailored (it doesn’t list dependencies that were not used in transformation); this is in contrast to the dependency graph collected at runtime, which is based on actual module dependencies.
MPS no longer creates runtime/sandbox solutions nested under a language module. By default, these modules would be siblings to the language module. Renaming the ‘main’ language module would still recognize these modules as ‘related’ and rename them along with the ‘main’ module.
To enhance the composite label key functionality introduced in previous releases, MPS supports keeping composite keys in checkpoint models.
The Cloning repository progress bar now appears on the Welcome screen and is shown right in the projects list, which makes it clearer and easier to use.
It’s now possible to quickly generate tables of contents in Markdown files based on the document headers.
It’s now possible to make a GPG signature in a commit. The signing will appear in the Commit Details section of the Git tool window.
When working with Markdown files that contain instructions with commands to execute, you can run those commands directly from the file by using the run icons in the gutter.
For every major release, we prepare instructions for migrating from older versions of MPS to ensure everything goes smoothly. Please review them carefully.