Quick fix tool

[MathiasSJacobsen]

Is it possible to access the Quick fix… button?

[msujew]

Hi @MathiasSJacobsen,

the Quick fix... button is populated by the CodeAction provided by the language server. We offer a basic CodeActionProvider interface, but no default implementation since that is highly language specific.

However, you can see it in action in the langium grammar language, where we use it to fix common mistakes. Currently, code actions work based on text changes, but we are thinking about adding additional utilities to provide code actions based on semantic changes (i.e. changes to the model which get translated into text changes).

[msujew]

Also, the link you shared is not valid anymore, I assume the file was moved to here.

@RobertWalterU3d Yeah, I should've used a permalink instead.

Are there any updates that could be shared about the mentioned utilities to provide "semantic code actions"?

Semantic code actions require a generic model serializer first. See the discussion in here. Due to it's high complexity, we've put off this feature, but we're slowly warming up to the idea. We're involved in some projects that would heavily benefit from that.

[RobertWalterU3d]

Can you share what you identified as main challenges/obstacles to do a semantic model serializer? (or point me to the discussion you mentioned in the other discussion that happened on Slack).

[msujew]

The internal slack discussion that we had was quite minimal, mostly just how difficult this could be. There are a lot of potential issues arising, since semantic model serialization is heavily ambiguous (compared to parsing, which isn't as ambiguous). Something like the following grammar as a simple example:

A infers X: 'a' name=ID;
B infers X: 'b' name=STRING;

Now let's say we want to serialize a model X { name: "someName" }. How do we know which rules to choose to serialize that element? Although the parsing of these rules is simple, serialization is ambiguous. Building a framework for serialization that catches all of these possible model permutations takes a lot of planning, effort and time. It's not impossible by any means (Xtext did it already a decade ago), but it's complicated nonetheless.

[RobertWalterU3d]

Thanks for taking the time to further clarify this for me, I appreciate that.

So, this example model X { name: "someName" } does not store meta-information about what it is, I assume? Sorry if my questions appear trivial, but I just have a different background, having worked at Intentional Software and a lot with MPS. I wonder how the example model you show was created in the first place. If it was created from an AST that has been parsed (which you mentioned would be easy), shouldn't the parser be able to add what "rule type" this model has, based on the parsing rule chosen?

In intentional trees, every node has to have a so-called "is-a", which points (roughly speaking) to a strong identity making it unambiguous what the semantics of each node are. MPS uses "concepts" in a similar fashion. I guess the main difference is that the central artifact in Langium is a grammar definition file and that the source files written in a concrete syntax are the source of truth from a DSL user's perspective?
And just to verify my understanding: the semantic model in Xtext was the EObject in-memory model (i.e. utilizing ecore as meta-model), right?

[msujew]

does not store meta-information about what it is, I assume?

Uhm, well, it's more like { $type: 'X', name: 'someName' } so it knows what it is, but not how it was created, since it wasn't created through a parser rule. Well it could be, but the whole node might also be completely synthetic. But yes, if we have a model which isn't completely synthetic but only slightly modified, the problem becomes simpler.

However, a code action might create arbitrary changes in the model, including completely new nodes. Consequently, semantic code action support needs to deal with that as well.

And just to verify my understanding: the semantic model in Xtext was the EObject in-memory model (i.e. utilizing ecore as meta-model), right?

Yep, you're correct :)