Community
Participate
Working Groups
Created attachment 233937 [details] grammar, test file, and stack dump I boiled down my grammar to the possible minimum to illustrate what I believe is a re-producable deadlock. Here's the grammar you can use in a default Xtext project (also attached). Note that I tried this with the latest release (2.4.2) as well as the bleeding edge version of Xtext (2.4.3.v201307291041): ############################################################# grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.common.Terminals generate myDsl "http://www.xtext.org/example/mydsl/MyDsl" Script: charactersDefinition=CharactersDefinition? scenes+=Scene*; CharactersDefinition: 'characters' ':' characters+=CharacterDefinition (',' characters+=CharacterDefinition)*; CharacterDefinition: name=ID; Scene: 'scene' description=STRING dialog=Dialog 'end' 'scene'; Dialog://{Dialog} defaults=Defaults hubs+=Hub*; Defaults: {Defaults} dialogLines+=DialogLine*; Hub: 'hub' name=StringID choiceDialogs+=ChoiceDialog* 'end'; StringID: STRING; ChoiceDialog: modifiers=Modifiers 'choice' name=StringID? dialogLines+=DialogLine* 'end'; Modifiers:{Modifiers} single?='single'? random?='random'? ; DialogLine: character=[CharacterDefinition] ':' lines=STRING; ############################################################# The grammar shows no warnings. Write a program using this language, which looks like this: ############################################################# characters: Foo, Bar scene "Test" hub "Foo" choice "Foo" Foo: "foooo" end // here you need to proceed to reproduce the deadlock... end end scene ############################################################# Save the above state once and then, manually(!), type the following at the marked position: choice "" and, when the cursor is just inside the quotation marks, invoke the content assist feature (CTRL+SPACE). This should lead to a re-producable deadlock. I attached the corresponding stack dump. The deadlock seems to appear when the main thread tries to acquire a read lock. I found two possible changes I can do to my grammar so that the deadlock does not appear. 1. Add the {Dialog} Action to the dialog rule (maybe the Xtext grammar should display another warning here that the action is missing since the "Defaults" rule might be empty?) 2. Change the "Modifiers" rule to an unordered group, which, however, led to other problems I cannot recall right now: Modifiers://{Modifiers} single?='single'? & random?='random'? ;
Could break that down to this grammar: grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.common.Terminals generate myDsl "http://www.xtext.org/example/mydsl/MyDsl" Root: 'root' name=STRING child+=Child* 'end'; Child: element=Element 'child' name=STRING 'end'; Element:{Element} name="FOO"? ; The problem seems to be the rule Child and it's first assignment in combination with the identical keyword "end" from rule Root and Child. Given this instance nothing wents wrong: root "root" child end end when you have this instance: root "root" child // Edit here! end And you try to edit at the described location the deadlock in the parser appears. If you change the keyword "end" at the end of rule root to "endroot" it works. If the Rule Element has a non optional assignment it works. If you remove the assignment element in rule Child it works.
Seema like line line 163 in org.xtext.example.mydsl.parser.antlr.internal.InternalMyDslParser loops to death because the loops keeps going even if LA1_0 is EOF. Removing this "LA1_0==EOF||" seems to solve the problem. do while(true) ... if ( (LA1_0==EOF||(LA1_0>=13 && LA1_0<=14)) ) { alt1=1; } Hopefully this helps to find the real issue.
I doubt that this is something that we can fix in the 2.4.3 timeframe.
You should try to avoid production rules that do not consume any input, e.g. ParserRule: {ParserRule} 'optional'?;