Bug 5618

Summary: Uncaught CompletionNodeFound exception doing code assist
Product: [Eclipse Project] JDT Reporter: Philipe Mulet <philippe_mulet>
Component: CoreAssignee: David Audel <david_audel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P2    
Version: 2.0   
Target Milestone: 2.0 M1   
Hardware: PC   
OS: Windows 2000   
Whiteboard:

Description Philipe Mulet CLA 2001-11-07 11:02:11 EST
Build 207 + JDTCORE from HEAD content (as of 20011107).

1 org.eclipse.core.resources 4 Unhandled exception caught in event loop.
Log: Wed Nov 07 17:00:46 CET 2001
4 org.eclipse.ui 0 Failed to execute runnable 
(org.eclipse.jdt.internal.codeassist.complete.CompletionNodeFound)

Was trying to perform a method declaration completion inside an anonymous
class:

Inside org.eclipse.jdt.internal.core.CompilationUnit
...
protected void 
codeComplete(org.eclipse.jdt.internal.compiler.env.ICompilationUnit cu, 
org.eclipse.jdt.internal.compiler.env.ICompilationUnit unitToSkip, int position, 
final ICodeCompletionRequestor requestor) throws JavaModelException {
	codeComplete(
		cu,
		unitToSkip,
		position,
		new ICompletionRequestor(){
			<CODEASSIST HERE>
		}
}
Comment 1 Philipe Mulet CLA 2001-11-07 11:05:30 EST
Actually the declaring class name was 'Openable'
Comment 2 Philipe Mulet CLA 2001-11-07 11:30:49 EST
Was able to reproduce on a simpler example:

public class X {

        void foo(){
                
                System.out.println(
                        new Runnable(){
                                <CODE ASSIST HERE>
                        }
                );
        }

}

Then select method 'run()' and insert it, the walkback occurs right after it in 
the UI (suspecting it triggers automatically another code assist at this point, 
which is the one crashing us).
Comment 3 Philipe Mulet CLA 2001-11-14 10:24:02 EST
Protection was added, but real defect should still be fixed
Comment 4 David Audel CLA 2001-11-26 11:16:08 EST
Fixed
Comment 5 Philipe Mulet CLA 2001-11-26 12:47:04 EST
I do not buy the fix, and re-released the original (still wrong) behavior.

The introduced flag isn't reinitialized when consumed and when doing recovery. 
The nestedMethod() action should be investigated more if offending.
Comment 6 David Audel CLA 2001-11-27 06:53:29 EST
push BlockInvocationPtr twice for method and constructor (and pop twice)