GRECLIPSE

Recognize ModuleNode.encounteredUnrecoverableError

Details

  • Type: Sub-task Sub-task
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.1.1Release
  • Fix Version/s: 2.6.1.M1
  • Component/s: Parser
  • Labels:
    None
  • Number of attachments :
    1

Description

The following code snippet should have ModuleNode.encounteredUnrecoverableError set to true.

package com.foo

import javax.swing.text.html.HTML


   void nuthin() {
		 if (! (this instanceof HTMLAccessibleContext/*_*/) {
            
         }
    }

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andy Clement added a comment -

I just created testUnrecoverableErrors_GRE949 in GroovySimpleTest with the code above and the module node returns true for encounteredUnrecoverableError() - is that snippet right (i.e. it has no class decl)?

Show
Andy Clement added a comment - I just created testUnrecoverableErrors_GRE949 in GroovySimpleTest with the code above and the module node returns true for encounteredUnrecoverableError() - is that snippet right (i.e. it has no class decl)?
Hide
Permalink
Andrew Eisenberg added a comment -

This is odd because when asked during a content assist invocation, encounteredUnrecoverableError() is set to false for the above snippet. Perhaps we can have a look at this tomorrow.

Show
Andrew Eisenberg added a comment - This is odd because when asked during a content assist invocation, encounteredUnrecoverableError() is set to false for the above snippet. Perhaps we can have a look at this tomorrow.
Hide
Permalink
Andrew Eisenberg added a comment -

Committed failing test case in project org.codehaus.groovy.eclipse.core.tests class org.codehaus.groovy.eclipse.core.compiler.UnrecoverableErrorTests.

Show
Andrew Eisenberg added a comment - Committed failing test case in project org.codehaus.groovy.eclipse.core.tests class org.codehaus.groovy.eclipse.core.compiler.UnrecoverableErrorTests.
Hide
Permalink
Andy Clement added a comment -

Ok, your test is failing for me. On examination I am not sure you could call it an unrecoverable error... because it recovered. I'll agree it isn't pretty but code was produced for some parts of the source.

Show
Andy Clement added a comment - Ok, your test is failing for me. On examination I am not sure you could call it an unrecoverable error... because it recovered. I'll agree it isn't pretty but code was produced for some parts of the source.
Hide
Permalink
Andrew Eisenberg added a comment -

But, there is no package declaration or any import statements. These are the things that Groovy-Eclipse uses to orient itself with respect to add/organize imports.

Show
Andrew Eisenberg added a comment - But, there is no package declaration or any import statements. These are the things that Groovy-Eclipse uses to orient itself with respect to add/organize imports.
Hide
Permalink
Andy Clement added a comment -

Here is a patch for GroovyRecognizer - it is handcoded recovery that will need working into the grammar if we want to go ahead with it. Please apply it and play around to see what happens. You may find on an error there are cascading secondary problems now because it won't immediately give up, it will try to continue (but it may be confused about where it has gotten to). This is causing problems for a few of the tests that pass in broken code and expect particular output.

Show
Andy Clement added a comment - Here is a patch for GroovyRecognizer - it is handcoded recovery that will need working into the grammar if we want to go ahead with it. Please apply it and play around to see what happens. You may find on an error there are cascading secondary problems now because it won't immediately give up, it will try to continue (but it may be confused about where it has gotten to). This is causing problems for a few of the tests that pass in broken code and expect particular output.
Hide
Permalink
Andrew Eisenberg added a comment -

Try to get this for 2.6.0.

Show
Andrew Eisenberg added a comment - Try to get this for 2.6.0.
Hide
Permalink
Andrew Eisenberg added a comment -

Revisiting this. I applied the patch and I am playing with the broken code in the description.

The goal is for organize imports to not remove everything if some kind of error has occurred and method bodies are empty. However, this patch does not do this.

After applying the patch, the nuthin method does exist in the module node, but it is an empty method with no statements. And hence invoking organize imports will remove the import statement.

Still some work to do.

Show
Andrew Eisenberg added a comment - Revisiting this. I applied the patch and I am playing with the broken code in the description. The goal is for organize imports to not remove everything if some kind of error has occurred and method bodies are empty. However, this patch does not do this. After applying the patch, the nuthin method does exist in the module node, but it is an empty method with no statements. And hence invoking organize imports will remove the import statement. Still some work to do.
Hide
Permalink
Andrew Eisenberg added a comment -

Now working. Fix was picked up with all the other fixes to parser recovery for 2.6.0. Including a regression test.

Show
Andrew Eisenberg added a comment - Now working. Fix was picked up with all the other fixes to parser recovery for 2.6.0. Including a regression test.

People

  • Assignee:
    Andrew Eisenberg
    Reporter:
    Andrew Eisenberg
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: