Example for custom references storing additional information (is this how langium is intended to be used?)

[goto40]

Thank you for the nice documentation (https://langium.org/docs/). I really appreciated the very clear description of the document lifecycle!
I made some experiments with custom references storing additional information: https://github.com/goto40/msg-dsl-mixed-lookup-and-path
I use langium 0.4.0.

//...
MsgArrayAttribute: 'array' name=ID ':' msg_type=[MsgType:FQN] '[' dim=[MsgArrayDim:FQN] ']';
                                                                // ^^^^^^^^^^^^^^^^^^^
interface MsgScalarAttributeRef {   // <---------------------
    path: MsgScalarAttribute[]
}

type MsgArrayDim = MsgConst|MsgScalarAttributeRef;
//...

I created a scope provider which creates elements of type MsgScalarAttributeRef and I would like to know if this is how it is intended to use langium (my solution works for me).

                const element: MsgScalarAttributeRef = {
                    $type: "MsgScalarAttributeRef",
                    path: entry[1]
                };
                // ...
               this.descriptionProvider.createDescription(
                    element, entry[0], getDocument(element.path[element.path.length-1])
                );

I am concerned about the reference to the document: I only link my reference to one document (element.path[element.path.length-1])), although I have elements from
more than one document involved in my reference.

[msujew]

Hey @goto40,

You're just trying to reference a single element using it's fully qualified name, right? Your approach is a bit unconventional/overengineered, since what you're trying to do can be relatively easily accomplished using the scoping in our domain-model example. Although your fully qualified name is a chain of elements, it actually only references a single element which is at the end of the chain. That's exactly what the domain-model scoping does.

Note that your approach using synthetic AST nodes also breaks a lot of LSP behavior, notably the go to definition and find references feature.

[msujew]

Nevermind, you're actually right. I didn't grok your code correctly. It is more like the MemberCall example, but you're using a single FQN and a synthetic element list instead of following a chain of real references. That makes sense, though I wouldn't recommend. Like I said, it breaks a few LSP services. For example, you cannot use the "go to definition" or "find references" feature, as the references aren't "real".

[goto40]

Thank you for the fast response!

[goto40]

Note that your approach using synthetic AST nodes also breaks a lot of LSP behavior, notably the go to definition and find references feature.

I just updated my scope provider: The synthetic AST node now "mimics" the final target (the last part of my path) by copying its contents:

                const element: MsgScalarAttributeRef = {
                    ...path[path.length-1],          // copy target AST node
                    $type: MsgScalarAttributeRef,    // type of new AST node
                    path: path                       // path to AST node
                };
                // now: return the new element into the current `Scope`

With this the "go to definition" feature seems to work - but not the "find references".

• Is the AST node used as key somewhere? My solution "mimics" the final target by copying its contents, but the new synthetic node is a different object than the final target.
• Any idea where to start to allow the find references feature...?

Notes:

• Since I store the path to my destination I wonder if there is a relation to Domainmodel example: refactor qualified name provider #236 (maybe a solution to Domainmodel example: refactor qualified name provider #236 will make my solution obsolete).
• I also tried the solution illustrated with the MemberCallabove: The problem is that I also have to lookup my constants the same way, but I ran into problems when using the same package name in different files (the wrong package was selected...). Maybe I start another discussion for that if I continue investigating.

[goto40]

I still use this approach here, since I do not see how resolve my problem here.

I have references of the form myref=[MyType:FQN], where I want to resolve from qualified name scoping and class member scoping.

My solution (see above: returning a synthetic AST element in my scope provider) "works" for me.
My main concern is: how probable is that my "solution" breaks with future version of langium?

[msujew]

My main concern is: how probable is that my "solution" breaks with future version of langium?

Very unlikely. We're quite happy with the current scoping infrastructure, and even though we might extend on it (see #1121), we don't plan on changing the APIs.