Check for duplicate defined variables

[ejfasting]

Hello,
I'm looking for some tips/pointers:

1. I need to add some duplication checks to my language, so that you get errors when you try to define a variable with the same name as one that already exists.
   I'm wondering what the optimal way would be to solve this.
   Only way i can think of is caching them as the document gets parsed, and after that check all new ones towards this cache with a validator, but maybe there is a better/builtin way?

I was thinking something like the sample for dependency-loops

2. I also want to validate that it's been defined before its used, so and give proper errormsg, but I cant seem to figure out where in AstNode this information is located (start-index and length).

/E

[msujew]

Hey @ejfasting,

Only way i can think of is caching them as the document gets parsed

Not possible, there is no hook during the parsing phase that allows to do so.

I'm wondering what the optimal way would be to solve this.

It depends on your data structure. In the Langium grammar language we can get away using a DFS for searching all rules and identifying those with duplicate names by creating a map of names:

langium/packages/langium/src/grammar/validation/validator.ts

Lines 174 to 177 in 89c0a9d

	checkUniqueRuleName(grammar: ast.Grammar, accept: ValidationAcceptor): void {
	const extractor = (grammar: ast.Grammar) => stream(grammar.rules).filter(rule => !isEmptyRule(rule));
	this.checkUniqueName(grammar, accept, extractor, 'rule');
	}

Often times you can also use the index to find those elements, that could be faster, and has the optional benefit of finding elements across multiple files.

I also want to validate that it's been defined before its used, so and give proper errormsg, but I cant seem to figure out where in AstNode this information is located (start-index and length).

You can use the $cstNode property of the AstNode interface. That should yield you exactly what you need. The AstNode is the abstract syntax tree node and therefore contains only abstracted information, whereas the $cstNode is the concrete syntax tree node which contains the information as it was parsed from the input text.

[ejfasting]

Thank you, then I believe I should be able to figure it out.

Looks like what you are doing in Langium works well enough.

You can use the $cstNode property of the AstNode interface. That should yield you exactly what you need. The AstNode is the abstract syntax tree node and therefore contains only abstracted information, whereas the $cstNode is the concrete syntax tree node which contains the information as it was parsed from the input text.

Bonus-question regarding this: My language has imports, but they work a little different then how it would in for example typescript (with import-statements at the top of the file).
In my language you can import file-content of file2 into certain places in file1. So you can have import-statements pretty much anywhere you want, and the imported content just gets injected into the main file.
Example:

String file1String= "foo"; 
#import 'file2';

myString = file2String; //file2String is a defined variable in file2

Whatever is in file2 gets injected into file1.

Does langium 'care' where the import-statements are defined?
And can i expect the $cst to include the position and length of the import-statement, and also the content of file2?
Based on my description (which i hope is good enough), can you forsee any issues with solving this in langium? An alternative would be to solve the imports on the client-side (vscode-extension), and pass the complete/generated file to the LSP, but it would require a lot of adjustments to the LSP features.

//e

[spoenemann]

In Langium, an import is just a filter of the global scope (collection of all exported symbols from all workspace files), selecting the symbols defined in a specific document. Typically, these are added as the outermost scope in the chain of scopes (usually each block of statements opens a new subscope). But it's perfectly fine to inject a filtered global scope somewhere in the middle of the chain of scopes, depending on where your import is declared. Your custom ScopeProvider is where you can describe this language-specific logic.

[ejfasting]

Great, thank you for the explanation @spoenemann, really appreciate the quick response! :)