Em um projeto Kotlin normal, você pode usar conjuntos de fontes para separar o código direcionado a diferentes plataformas. No MPS, isto foi introduzido no nível da raiz, com a opção de especificar o conjunto de plataformas suportadas para cada nó raiz do Kotlin. Esses conjuntos de fontes podem ser configurados no nível do nó raiz com a ajuda de uma ação de intenção.

Na prática, isso significa que:

• O código em um determinado conjunto de fontes só pode acessar declarações com plataformas compatíveis. Por exemplo, o código específico da JVM pode acessar somente o código específico da JVM e o código comum direcionado à JVM.
• Os códigos-fonte gerados são estruturados em diretórios específicos do conjunto de códigos-fonte. Se um diretório não for especificado, ele usará o conjunto de fontes padrão, que corresponde ao padrão do módulo.
• Agora, há suporte para declarações esperadas e reais.

Por padrão, o código Kotlin sem uma plataforma explícita usa a JVM, mantendo a compatibilidade com versões anteriores.

O código Kotlin no MPS costumava gerar muitos erros de escopo e typesystem quando o plug-in Kotlin Typesystem, baseado em CodeRules, não estava disponível. Para melhorar a legibilidade e a capacidade de testes, essas verificações e erros agora são silenciados quando o plug-in de sistema de tipos baseado em CodeRules não está disponível.

Nesses casos, todos os escopos nas linguagens Kotlin são substituídos por um escopo padrão que inclui todos os nós de conceitos compatíveis. Isso elimina qualquer erro falso-positivo, pois todos os nós válidos estão dentro do escopo.

As diretrizes para lidar com o código Kotlin permanecem as mesmas de antes:

• A escrita e a verificação do código Kotlin devem ser feitas com o CodeRules ativado habilitado o plug-in Kotlin Typesystem instalado.
• A leitura e a geração do Kotlin podem ser realizadas com segurança sem eles.

O painel Logical View agora é baseado em uma arquitetura assíncrona, o que ajuda a manter a IU responsiva e contribui para o desempenho geral do IDE. A nova implementação também permite extensões e modificações mais fáceis. Para obter mais detalhes, consulte nosso artigo na base de conhecimento: ProjectPane implementation on top of ProjectViewTree (Implementação do ProjectPane sobre ProjectViewTree).

Essa nova implementação resultou em algumas mudanças notáveis:

• Indicadores de erro e aviso não estão mais disponíveis.
• Erros e avisos encontrados na hierarquia estão sublinhados em vermelho.
• A opção Show Descriptor Models afeta todos os modelos de descritores.
• Algumas operações de arrastar e soltar funcionam de maneira diferente.
• As configurações no painel Logical View foram ligeiramente reorganizadas.

Introduzimos um novo estilo em BaseLanguage que permite que células constantes sirvam como espaços reservados se houver um valor ausente (um nó filho ou uma referência). Por exemplo, quando nenhum construtor está presente numa classe, uma célula de espaço reservado poderá ser exibida <no default constructor>. O estilo faz com que as células constantes exibam o comportamento que você esperaria dessas células de espaço reservado. O cursor só pode ser colocado na primeira posição, e não é possível editar o valor. Somente as modificações fornecidas pelos menus de transformação anexados são permitidas.

A opção booleana doNotCompile dos módulos na linguagem de build foi substituída por um enum Java para distinguir melhor os casos em que:

• O módulo não contém código.
• O módulo contém código, mas o código é compilado por ferramentas diferentes do MPS.

Esses dois casos costumavam ser representados pelo valor true.

A nova enum Java tem três valores possíveis:

• compile in MPS
• compile externally
• no code

Ao migrar para 2024.1, o valor original false de doNotCompile será migrado para compile in MPS, enquanto o valor true de doNotCompile será migrado para compile externally.

Um pequeno recurso experimental permite que você adicione um fork para um plano de geração sem modificar o plano original que está recebendo fork. Um plano de geração pode ser marcado como um fork de outro plano de geração. O plano marcado será tratado como se fosse referenciado explicitamente com a instrução padrão fork inserida no início do plano de geração com fork.

Além disso, ao definir um fork, você pode usar um modificador de string que servirá como gatilho. O fork só ocorrerá se o modelo que estiver sendo gerado for de propriedade de um módulo que tenha uma faceta de destino de geração com um ID de faceta que corresponda ao gatilho de string.

Testes JUnit no MPS agora podem gerar relatórios de teste não apenas nos formatos Vintage e Jupiter, mas também no formato Open Test Reporting. Uma nova opção está disponível nas opções de teste da linguagem de build para controlar se o relatório Open Test está incluído nos relatórios gerados. Se a opção for definida como true, os arquivos de relatório denominados junit-platform-events*-$BUILD_NAME$.xml serão criados no diretório do projeto.

Se a opção for definida como false, serão criados os relatórios antigos para os mecanismos Vintage e Jupiter.

Os relatórios de teste MPS agora respeitam a anotação JUnit @DisplayName e propagam o nome para os relatórios exibidos na janela da ferramenta de relatório de teste.