Community
Participate
Working Groups
I20090325-1135 An ASTParser for kind K_CLASS_BODY_DECLARATIONS cannot parse a method declaration with syntax errors, although setStatementsRecovery(true) has been called. When I copy the method foo() below to the clipboard and then paste it to the Package Explorer, this doesn't create a snippet: void foo() { Integer I = new ${cursor} } But when I add a dummy class declaration around it, then an ASTParser for K_COMPILATION_UNIT can create an AST: public class Try { void foo() { Integer I = new ${cursor} } } I would expect the K_CLASS_BODY_DECLARATIONS to use the same error recovery.
I would also expect the same error recovery.
Not only the recovery doesn't work, but it returns a compilation unit node when the documentation says that only a type declaration can be returned. So both issues must be fixed.
Created attachment 130235 [details] Proposed fix
Returning a compilation unit is fine in case the source contains errors and the recovery is not enabled. I'll update the patch accordingly.
Released for 3.5M7. Added regression tests in: org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2#test0702 org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2#test0703 org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2#test0704 org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2#test0705 org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2#test0706 org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2#test0707 org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2#test0708 I forgot to generate a new patch before I committed the code.
Verified for 3.5M7 using build I20090426-2000
Note that while testing changes in the code formatter, I saw some strange behavior around this fix... Consider the following snippet: class MyCommand extends CommandBase { protected Command subcommand; //... public void execute() { // ... Compound subcommands = new CompoundCommand(); subcommands.appendAndExecute(new AddCommand(...)); if (condition) subcommands.appendAndExecute(new AddCommand(...)); subcommand = subcommands.unwrap(); } public void undo() { // ... subcommand.undo(); } public void redo() { // ... subcommand.redo(); } public void dispose() { // ... if (subcommand != null) { subcommand.dispose(); } } } Before the fix was applied, parsing the snippet using the Parser.parseClassBodyDeclarations(...) method returned null. After the fix (e.g. using HEAD), it returns an array with one TypeDeclaration and it seems to be the expected result. However, considering another snippet: class MyCommand extends CompoundCommand { public void execute() { // ... appendAndExecute(new AddCommand(...)); if (condition) appendAndExecute(new AddCommand(...)); } } parsing it with the same method still returns null. After the fix was applied, I would expect a non null result for both snippets... Did I miss something?
(In reply to comment #7) Please file a new bug for that problem.
(In reply to comment #8) > (In reply to comment #7) > Please file a new bug for that problem. > I opened bug 280063 for it...