Module Cloning supported
We introduced a new action that provides module cloning facility. To clone a module you should select it in the project menu and click on `Clone Solution/Language` action in the context menu. You can see full documentation on clone module action here.
Cross-model generation support (experimental/work-in-progress functionality)
New language features in j.m.lang.generator.plan to address plan extensibility story:
- 'apply with extended' statement. Takes specified generators and those that extend these for the languages utilized in a model, and apply them as a single step. This mechanism allows plan designer to accommodate possible extensions to its languages/generators. It's expected that MPS would additionally respect priorities between involved mapping configuration in the upcoming releases.
- 'declare checkpoint <checkpoint>' and 'synchronize with <checkpoint>' statements. To share synchronization points between different plans, we captured different aspects of a checkpoint with distinct statements. Use 'declare checkpoint' to specify a token plans could share. Regular 'checkpoint <checkpoint>' statement may reference a checkpoint declared elsewhere (it's still possible to declare checkpoint in-place). This statement within a plan records/persists state of transformed model under designated checkpoint. And the last one, 'synchronize with <checkpoint>', tells generation plans to look up target nodes in a persisted models of specified checkpoint. This statement doesn't introduce any new state (model being tranformed is not persisted for checkpoint we synchronize with) and always references a checkpoint declared elsewhere.
Checkpoint models are denoted with a stereotype that matches name of a checkpoint the model has been created with. Models are persisted along with generated sources using naming scheme <plan-name>-<checkpoint name>.
Context objects in TextGen
Although rarely needed, functionality to keep context information during M2T transformation of a text unit might be vital for certain scenarios (like BaseLanguage, where TextGen has to track model imports and qualified class names). In previous MPS versions, this has been approached with combersome and low-level code utilizing
buffer object. Now, it's possible to specify necessary object as part of concept's textgen specification. At the moment, regular java class (with a no-arg or a single-arg constructor that takes concept instance) are supported as context objects.
Declare a context object and bind it to an accessor:
Associate with a concept's textgen:
Reference from code as a regular variable:
New handy operation in bl.collections
To filter out null elements of a sequence, verbosity of
seq.where(it => it != null) could be addressed with
Find Usages for Mapping Configurations
It's been a tedious work to find out what priority rules use given
MappingConfiguration. Now, Find Usages looks up occurrences of a MC and shows them inside stubs for project modules:
Bootstrap Dependency in a Language Accessory model
MPS now treats accessory model that uses its own language as an error if the model could be generated ('Do not generate' flag not set). It's impossible to generate such model unless the language is generated, and as long as the model is part of the language, MPS is stuck. Previous MPS versions allow this scenario by silently assuming language has no generators (therefore, nothing would be generated), now MPS wants Language Designer to be explicit about own intentions and to denote model as 'Do not generate'.
If an accessory model doesn't use its hosting language, MPS still warns about generatable model as the primary scenario for accessory model is to supply nodes, not generated code.