Transitive imports of namespaces

[tfonda-fbk]

Hi,
I am developing a DSL exploiting the very handy inbuilt support Xtext has for namespace-based imports (with and without wildcards). However, my language must also support transitive imports of namespaces. In other words, I want these three files to parse correctly:

Foo.mydsl, that contains

package Foo {
    item foo_a;
    item foo_b;
}

Bar.mydsl, that contains

package Bar {
    import Foo.*;
    item bar_a;
    reference foo_b; // Easy, this works out of the box.
}

Baz.mydsl, that contains

package Baz {
    import Bar.*;
    reference bar_a; // Again, easy.
    reference foo_b; // Hard!
}

Inside package Baz all elements of package Bar are imported, and I want this to trigger an import of all the elements imported inside package Bar too, i.e. those of package Foo (and so on).

I have read this tutorial but it only applies to languages in which files, and not namespaces, are imported. It does not seem trivial to me to adapt what is done there to my case (but maybe it is).

Has anyone got any advice for me on how to implement this kind of transitive imports?
Thanks a lot!

[tfonda-fbk]

Hi, I have somehow figured out how to implement this functionality, although it is not 100% usable yet. I will soon write a detailed post explaining what I did, what is working correctly and what is not, hoping that someone is able to help me and it can be of help to future DSL developers too.

[tfonda-fbk]

Hi, I have made further progress, and now I am ready to share what I have been able to accomplish.

To implement the desired functionality, I extended the default ImportedNamespaceAwareLocalScopeProvider as shown in this Gist. (Mind that the class structure is not very elegant, this is still work in progress.)

The main change lies in the getLocalElementsScope() method, which is mostly copy-pasted from the base class. On line 115, I have changed the initializer of the List<ImportNormalizer> namespaceResolvers local variable. My custom method recursively explores import statements, starting from the current context and entering each element imported by each import statement, to look for other import statements, and so on. A map is used to cache intermediate results (i.e. lists of ImportNormalizers built for a given root context), to improve performance.

This, however, was not enough to make import statements work as I wanted. At this point, transitive imports only worked in cases such as the example outlined in my first post, where Baz.mydsl imports Bar.mydsl and references an element defined in the latter file. This seemed to be required in order to "trigger the loading" of Bar.mydsl, and thus the transitive import resolution that finally made elements of Foo.mydsl visible in Baz.mydsl. If I had removed reference bar_a; // Again, easy. from Baz.mydsl, the cross-reference to foo_b would not have been resolved.

The crux of this problem lied in the default Xtext ResourceSet population strategy. I am sure the following interpretation is imprecise, but as a beginner I think of a Resource as a file (a DSL file in one of my DSL projects), and of a ResourceSet as an ensemble of files (e.g. all DSL files in the DSL project I am working on, ideally). It looks like Xtext loads Resources into ResourceSets lazily, so unless some file A references an element contained in file B, file B (or better, the Resource associated with file B) will not be loaded in the ResourceSet containing the Resource associated with file A. As a consequence, transitive import resolutions that transit through an import contained in file B will not be carried out.

To work around this issue, I had to add lines 110-113 to my getLocalElementsScope() implementation, to make sure that any ResourceSet instantiated by Xtext is populated with Resources associated with all SysML v2 files in my project. This bit of code and the three static fields that are related to it really need to be moved somewhere else, ideally to some place where they can be executed only once on project/editor loading (I have not figured out where this might be), with a helper method that takes a ResourceSet as a parameter and populates it if empty.

Please disregard my implementation of doCreateImportNormalizer() and my custom SysMLv2ImportNormalizer class. They are there for a different reason.

I hope what I wrote can be useful for other developers in the future. If anyone has got any feedback on this, I would very much appreciate it to read it :)