Switch entry rules without separate language by file extension

[cdietrich]

• we have a quite close set of languages that basically share the same grammar
• in each of these languages the only thing that differes is the root element
• our file extension use the pattern name.<rootindicator>.extension

is there a way to keep just one language and just switch the entry rule of the parser based on the uri and thus avoiding ending up with a big bunch of languageids whilst we otherwise share everything between the languages?

[msujew]

Hey @cdietrich,

you should be able to override these functions:

langium/packages/langium/src/workspace/documents.ts

Lines 303 to 311 in c3afb24

	protected parse<T extends AstNode>(uri: URI, text: string, options?: ParserOptions): ParseResult<T> {
	const services = this.serviceRegistry.getServices(uri);
	return services.parser.LangiumParser.parse<T>(text, options);
	}
	protected parseAsync<T extends AstNode>(uri: URI, text: string, cancellationToken: CancellationToken): Promise<ParseResult<T>> {
	const services = this.serviceRegistry.getServices(uri);
	return services.parser.AsyncParser.parse<T>(text, cancellationToken);
	}

They have access to the URI of the file and you can pass in a different set of parser options into the parser based on that URI. Note that you can just call LangiumParser.parse in the parseAsync call, as the AsyncParser currently does not support passing in options.

[msujew]

Yes, that makes sense 👍

[cdietrich]

@msujew how does the completion provider finds it rule?
i guess we'd need to hook into

parse(input: string): CompletionParserResult {

[cdietrich]

unfortunately the completion parser is not really subclass friendly

[msujew]

Ah, right. Perhaps you can filter the results instead? It should only affect the entry rule, right?

[cdietrich]

yes. this is our other solution we try to replace with this question

[spoenemann]

The approach we've taken in earlier projects, both with Xtext and with Langium, is to combine all file types in a single entry rule and then add validations that forbid certain elements based on the URI.

[cdietrich]

yes this is our current approach (+ a filter in content assist)