Thursday, October 22, 2015

The Xtext Grammar Learned New Tricks

Since the Xtext 2.9 release is around the corner - and you've for sure read about the upcoming support for IntelliJ IDEA or Xtext editors in the browser -, it's time to unveil some of the new features of the Xtext grammar language itself. In a nutshell the enhancements address a couple of long standing feature requests and non-critical issues that we had. But especially complex grammars sometimes required duplicated or repetitive parts to implement the language syntax. We felt that it was about time to get rid of these idioms.
Long story short: In the next version the grammar language will support a couple of new features:
  1. /* SuppressWarnings[all] */: The severity of errors and warnings in a grammar file can be customized on a per project level since Xtext 2.8. But sometimes you don't want to disable the validation rule completely just to get rid of one particular false positive (False positive?!? you think? Stay tuned, I'll elaborate on that in a separate post). For that purpose it's now possible to mute a certain validation rule for a selected element, a rule or the entire grammar.
  2. super calls and grammar mixins: Xtext 2.9 renders our former advise 'You have to copy the parent rule into your sub-language' obsolete. Eventually it is possible to simply use a super call instead.
  3. A long standing feature request for the grammar described a means to extract common parts of parser rules without screwing up the ecore model. The newly introduced parser fragments allow to normalize production rules that formerly required copy'n'paste, e.g. due to left factoring. Fragments even sport smarter inference of the ecore model when it comes to multiple inheritance.
  4. Last but not least, the new JavaScript specification was an inspiration for conditional alternatives in a grammar definition. Advanced language use cases may require to enable or disable a decision path deep down in some recursive chain of rule calls. Until now there was no concise way to support something like that. This limitation led often to dozens of copied rules if a syntax required to support conditionally enabled or disabled branches. Parameterized rule calls remove that limitation and enable much more expressive notations.
I'll explain all these new features in-depth in a short blog series to make sure that every bit of it gets proper attention. Make sure to follow-up if you are curious about them.

3 comments:

Yaniv Saar said...

Hi Sebastian,
I see in the sources that 2.9 also adds support for casesPerSpecialStateSwitch option.

For some reason when setting this field in the ANTLR fragments, it does not have any affect on the construction of the Lexer DFA (eventually leading me to error "The code of method specialStateTransition(int, IntStream) is exceeding the 65535 bytes").

Is it an half baked feature?
Should I do anything other than adding "options = {casesPerSpecialStateSwitch="8"}" in the ANTLR fragments (parser.antlr.XtextAntlrGeneratorFragment, and parser.antlr.XtextAntlrUiGeneratorFragment)?

aliya seen said...

Our online punctuation corrector are working on your principles. This is definitely different, though I guess I kind of like looking at the question of what happens after you kind of save the world but maybe doom I think you'll like book three though.

Роман Чумак said...

Hi .
The code completion proposal should include some options as non-active options (i.e. cannot click/add them;)
The options should be in the end of the list and greyed out.
How can i disable options in content proposal?
I could not find solution of this area but i guess i should use class ConfigurableCompletionProposal.
It would be a nice to see some code example.
Thanks.