Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 320941 - AbstractContentAssistParser.getFollowElements() fails to find element when error recovery is involved
Summary: AbstractContentAssistParser.getFollowElements() fails to find element when er...
Status: CLOSED INVALID
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 1.0.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: SR1   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-26 13:43 EDT by Martin Schnabel CLA
Modified: 2010-07-27 14:31 EDT (History)
2 users (show)

See Also:
sebastian.zarnekow: helios+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Schnabel CLA 2010-07-26 13:43:37 EDT
Build Identifier: 

i have a grammar[0] with class definitions similar to java. the grammar is heavily dependent on backtracking and thus makes use of error recovery very often. when the content assist parser tries to find the following token after "extends" it will return an empty list.

public class A extends |B {
}

i took a look at org.eclipse.xtext.ui.editor.contentassist.antlr.AbstractContentAssistParser.getFollowElements(AbstractInternalContentAssistParser, AbstractElement, String[], int)

the first time error recovery kicks in "wasRecovering" is set to true in line 128. it will never be set to false again for the same ruleName.
thus it will never set "consumedSomething" for my parser rule in line 112.
however when i simply add "wasRecovering = false" inside endErrorRecovery method in line 124 it will work like i would expect.

but because it is called wasRecovering and not isRecovering i am not sure if the code would still work as intended after my simple fix.

[0] http://new.axdt.org/browser/as3/as3-runtime/src/main/java/org/axdt/as3/As3.xtext

Reproducible: Always
Comment 1 Sebastian Zarnekow CLA 2010-07-26 15:52:03 EDT
The input 

class A extends |B {
}

produces the valid proposal A.

Can you confirm, that the bug is reproducable with the latest version from CVS Head?

I'ld assume the issue is related to bug 314143
Comment 2 Martin Schnabel CLA 2010-07-27 09:38:57 EDT
yes it it works with cvs head. thanks!
and sorry for not testing with head before reporting, xtext set-up takes way to long with 80 kb/s downstream so only checked if AbstractContentAssistParser changed.
Comment 3 Sebastian Zarnekow CLA 2010-07-27 14:31:07 EDT
Thanks for testing with HEAD.