[parser] Better parser recovery

This bug is getting more critical as we rely more and more on Groovy functionality and JDT reliance is removed. Bumping up the priority.

Some basic recovery for (1) is in. Far from perfect but it hangs together.

#1 is still not looking so good. This class fails to parse:

class Sample {
	def x = new A
} 

I would be expecting that the GCUD would be populated with a

type and this type would have an

field. But it seems that the default, empty module node is created instead.

well if you keep changing the requirements.... please give me complete programs that you expect to recover from. All the tests I added were around basic new as shown in #1. If you need 'def x = new A' that could very well be something entirely different.

i also think requests for different recoverable constructs should be in entirely different bugs otherwise some will get lost - they typically all require very different changes.

OK...will create sub-tasks. However, even when I try this, it is apparent that structure is not being built since import statement does not appear in the outline view.

import javax.swing.text.html.HTML
HTML h 
new Earth

Actually, I just added a testcase for

class Sample {
  def x = new A
}

and it passes just fine.

this.runNegativeTest(new String[] {
				"XXX.groovy",
				"class Sample {\n"+
				"  def x = new A\n"+
				"}"
				},
				"----------\n" + 
				"1. ERROR in XXX.groovy (at line 2)\n" + 
				"	def x = new A\n" + 
				"	        ^\n" + 
				"Groovy:unable to resolve class A \n" + 
				"----------\n" + 
				"2. ERROR in XXX.groovy (at line 2)\n" + 
				"	def x = new A\n" + 
				"	            ^\n" + 
				"Groovy:expecting \'(\' or \'[\' after type name to continue new expression @ line 2, column 15.\n" + 
				"----------\n"
				);
		checkGCUDeclaration("XXX.groovy",
				"public class Sample extends java.lang.Object {\n" + 
				"  private java.lang.Object x;\n" + 
				"  public Sample() {\n" + 
				"  }\n" + 
				"}\n");

Are we on the same page in terms of expectations here?

Yes, that is the behavior I'd expect, but I'm not seeing that. I just confirmed that I have the latest from trunk.

On this:

import javax.swing.text.html.HTML
HTML h 
new Earth

I'm finding the import declarations section in my outline view (which I normally have closed, just opened it today) come and go randomly regardless of whether new Earth is in there. My simple test.groovy file is:

import java.lang.String
def a = 5

I also tried with a non system import 'com.foo.Andy' (java type defined elsewhere).

After fiddling for a while I do eventually see the import declaration appear (just making minor changes and saving)
Then I removed the import for java.lang.String, it disappeared from the outline, I then re-added it and it did not appear again in the outline.

ah, with respect to my previous comment it may be more that the import section is randomly expanding and flattening on changes - I didn't realise the little opener was faded out. What is the rule for it expanding automatically, is it supposed to be only when I make a change to imports? or only when I click the expander? I can't work out what is triggering it.

Now I know it sometimes shuts itself, this

import javax.swing.text.html.HTML
HTML h 
new Earth

is correctly showing me the imports - that is the latest installed groovy from the update site. Do you not see that?

Arrgh. Sorry about that. Looks like I was running under Groovy 1.6.5. I'd forgotten that I have been running that way occasionally in order to ensure backwards compatibility.

Appears to be working now. Thanks for implementing.

Wasn't happy with the recovery as I mentioned, so I've reworked it, now it is pretty spectacular. It will give you all 7 errors in this:

class C {
  public void m() {
  new Earth
     new Air
    new
 new Fire
 def leppard = 'cool'
  }
}

3 missing '(' errors, 1 new that misses a type name and 3 can't resolve type (earth/air/fire)

due to how I am implementing recovery, I'm using a mark/rewind - it isn't clear to me if mark has any impact on performance (and so would be affecting 'normal' valid code).

No longer critical since lots of good work has been done on this.

Continue this work towards 2.1.0.

I created org.eclipse.jdt.groovy.core.tests.basic.FailingErrorRecoveryTests that contains 8 tests for error recovery. One or two for each of the subtasks on this bug report. 5 are still failing. Hopefully, this should help you fix the problems.

although all the sub issues are fixed, there doesn't appear to be one for the case (2) in the original description.

case (2) also fixed, closing this.