File-based scoping, builtin library and performance

[ejfasting]

Hello,

I have a pretty big builtin library which contains classes that is used in my language.
I'm wondering how to best approach getting file-based scoping to work in tandem with this library. In other words its just file-based scoping with an additional library which should always be available.

From looking on a couple of other threads, and going through the documentation it looks like getScope is the correct place to do one of the following:

1. Override getGlobalScope and create a custom MapScope with only the URIs i want. Here i can 'inject' my builtin library:

    protected override getGlobalScope(referenceType: string, context: ReferenceInfo): Scope {
        const document = AstUtils.getDocument(context.container);

        // Get all included documents
        const grammar = document.parseResult.value as Grammar;

        const currentUri = document.uri;
        const currentDir = dirname(currentUri.path);

        const uris = new Set<string>();

        uris.add(document.textDocument.uri);
        uris.add("builtins:/library");

        for (const fileImport of grammar.includes) {
            const filePath = join(currentDir, fileImport.file);
            const uri = currentUri.with({ path: filePath });
            uris.add(uri.toString());
        }

        return new MapScope(this.indexManager.allElements(referenceType, uris));
    }

2. Filter/override the result received from the default getGlobalScope:

  protected getGlobalScope(referenceType: string, _context: ReferenceInfo): Scope {
        return this.globalScopeCache.get(referenceType, () => new MapScope(this.indexManager.allElements(referenceType)));
    }

Option 1 does work, but it comes with a performance-hit..
Option 2 seems to be rather tricky (?)

Am I misunderstanding how this works, and if so is there a recommended way of doing this?

Any advice is appreciated! :)

//Eivind

[msujew]

Hey @ejfasting,

I believe you're pretty much there. Recomputing the global scope is always quite expensive, which is why the DefaultScopeProvider caches the global scope. You should be able to do the same to fix the performance issue:

    private documentCache: DocumentCache<string, Scope>;
    ...
    protected override getGlobalScope(referenceType: string, context: ReferenceInfo): Scope {
        const document = AstUtils.getDocument(context.container);
        const currentUri = document.uri;
        return this.documentCache.get(currentUri, referenceType, () => {
          const currentDir = dirname(currentUri.path);

          const uris = new Set<string>();
  
          uris.add(document.textDocument.uri);
          uris.add("builtins:/library");
          const grammar = document.parseResult.value as Grammar;
  
          for (const fileImport of grammar.includes) {
              const filePath = join(currentDir, fileImport.file);
              const uri = currentUri.with({ path: filePath });
              uris.add(uri.toString());
          }
  
          return new MapScope(this.indexManager.allElements(referenceType, uris));
        });
    }

[ejfasting]

Hi @msujew ,

Then i wasnt to close to my goal, that's good :)

I hope it's OK if i follow up in this thread with a separate/another question:
I have both classes and enums defined in my definition-language. This means I end up with a syntax that looks like this (simplified):

class myClass { }
enum myEnum {}

class userClass {
 myClass classReference();
 myEnum enumReference();
}

I'm wondering if this crossReference for this can be solved with the grammar itself?
When i try to solve this in the grammar it always tries to crossReference to a class => Could not resolve reference to Class named 'myEnum'.. It make sense since Class and Enums in this case are returnTypes, and the parser dont (as far as I can tell) say it could be one or the other.

I created a short sample on the playground.
By looking at the syntax tree I could just check if type.classType.$type is undefined, which should mean its a enumReference, but I need to figure out where to inject this check and if its the correct way to do it.

//Eivind

[msujew]

You're trying to do something that doesn't work in the parser world:

TypeReference:
    (classType=[Class:ID] | enumType=[Enum:ID])
;

From a parser perspective, this looks just like this:

TypeReference: ID | ID;

The parser cannot decide which ID alternative is supposed to be chosen, therefore, it will always pick the first one. The parsing phase is completely unaware of the linking feature of Langium. The parser even prints this into the console:

Ambiguous Alternatives Detected: <0, 1> in <OR1> inside <TypeReference​> Rule,
<ID, ID> may appears as a prefix path in all these alternatives.
See: https://chevrotain.io/docs/guide/resolving_grammar_errors.html#AMBIGUOUS_ALTERNATIVES
For Further details.

In this case, it will assume that you want to reference a Class. You can easily fix this though by targeting a common type of Class and Enum:

TypeReference:
    (typeRef=[DefinitionElement:ID])
;

[ejfasting]

Right, that makes so much sense, thank you! :)

//e