Langium 2.0.0, loading documents effect

[goto40]

We are just switching to langium 2.0.0. It seems there are many great things you did (e.g., better scoping). Thank you for that!

We have a langium language project, where we have models using "imports" (which means we reference across model files). Imports are only validated (to detect import errors) and not used for scoping (as suggested in #458).

Normally we load whole folders/workspaces (like vscode). This works as before:

await services.shared.workspace.WorkspaceManager.initializeWorkspace([{
            uri: URI.file(path.resolve(folder)).toString(), 
            name: 'cli-workspace'
        }]);

Also when using the IDE (vscode) everything works (no error).

Our problem: However, we also have a special loading function which analyzes the loaded models (before link resolution) and collects relevant files by analyzing the imports):

await services.shared.workspace.WorkspaceManager.initializeWorkspace([]);

services.shared.workspace.LangiumDocuments.getOrCreateDocument(uri1) // uri1 imports uri2 and uri3
services.shared.workspace.LangiumDocuments.getOrCreateDocument(uri2)
services.shared.workspace.LangiumDocuments.getOrCreateDocument(uri3)

const docs = services.shared.workspace.LangiumDocuments.all.filter(d=>d.uri.scheme==='file').toArray(); // we have a builtin model file (seems not to be involved in the linking error)
await services.shared.workspace.DocumentBuilder.build(docs, { validation: true });

After migration to langium 2.0.0 we get a linking-error for that case. The documents in services.shared.workspace.LangiumDocuments.all are the same in bot cases.

I checked DefaultWorkspaceManager.initializeWorkspace: is it harmful to call await this.documentBuilder.build twice? (like in our case)? Is it ok to call await services.shared.workspace.WorkspaceManager.initializeWorkspace([]);?

[msujew]

Is it ok to call await services.shared.workspace.WorkspaceManager.initializeWorkspace([]);?

Yes, that's perfectly fine if there's no real workspace available.

is it harmful to call await this.documentBuilder.build twice?

No, that shouldn't be an issue. By default the document builder just rebuilds the documents that you give it + the documents which either contain linking errors or haven't finished the full build yet. build should never be a destructive action.

We did quite a large refactoring in 2.0.0 of the document builder with #1094. There might be a regression that we introduced accidentally, though I'm not sure how. Without looking deeper/debugging this issue, I can't really tell what the issue is. Can you provide a reproducible example for us?

[goto40]

Thank you very much for that quick response.

Unfortunately, a small example did not allow reproduce the error.

I observerd, that let result = this.getGlobalScope(referenceType, context); in the DefaultScopeProvider differs in both cases depicted above (the 'good' case and the 'bad' case where we load using imports):

• in the good case I see that relevant globals are "Published" in our MessageDslScopeComputation.computeExports AND is returned by DefaultScopeProvider.getGlobalScope(referenceType, context);
• in the bad case I also see that relevant globals are "Published" in our MessageDslScopeComputation.computeExports but some (the relevant) are not returned by DefaultScopeProvider.getGlobalScope(referenceType, context);

Any ideas how I can further analyze my problem? (In any case I will dig further)

[msujew]

I see, then you're likely hitting an issue that originated in #1121. Now I see that the global scope cache isn't cleared upon calling build only on update. This isn't an issue in the language server case, since we call update in there, but calling build manually doesn't trigger the update listeners.

You can override the document builder and call the onUpdate emitter in the build method. See here. It might make sense for us to make this the default behavior.

[msujew]

I've created a fix for this in #1190.

[goto40]

Thanks again for your excellent support!

• Overriding the document builder and call the onUpdate emitter was not solving my problem. (see comments below: Emit onUpdate event on DocumentBuilder#build #1190 fixes the problem)
• But: clearing the cache solved the problem.

I added a method clearCache in my ScopeProvider:

    clearCache() {
        this.globalScopeCache.clear();
    }

Then calling clearCache before await services.shared.workspace.DocumentBuilder.build(docs, { validation: true });solves my problem.

Do you understand what happend?

[msujew]

You're welcome, I'm glad you were able to solve the issue :)

Overriding the document builder and call the onUpdate emitter was not solving my problem.

How did you call the emitter? Because the global scope cache should clear itself on update, see here.

[goto40]

My bad! I am sorry: copying the build and the emitUpdate from your current main into my custom Documentbuilder solves the problem! :-) Good work @msujew !!!

When will this patch be available (I have my workaround, but if you know...)?

[msujew]

We don't have a definitive release date for 2.1.0 yet, but I assume something like the end of September.

[goto40]

No hurry. Thanks again!