Community
Participate
Working Groups
Build Identifier: Version: 3.6.2, Build id: M20110210-1200 ASTParser parsed with K_STATEMENTS kind and the source contains an empty for loop (e.g. for{};) returns the empty/partial ASTNode. Tried with parser.setStatementsRecovery(true) also. I want to parse the code and find analyze it. So, even with errors (syntax/semantic errors in th code), I would like to get the AST with recovered statements and problems. I have attached the running test case code and let me know if there is any work around to get the full AST node. Thanks in advance. Reproducible: Always Steps to Reproduce: Sample code to test this behavior: if you use the commented out source, AST is returned properly and my visitor could visit all the nodes. =================================================== import java.util.HashSet; import java.util.Set; import org.eclipse.jdt.core.dom.AST; import org.eclipse.jdt.core.dom.ASTNode; import org.eclipse.jdt.core.dom.ASTParser; import org.eclipse.jdt.core.dom.ASTVisitor; import org.eclipse.jdt.core.dom.Block; import org.eclipse.jdt.core.dom.CompilationUnit; import org.eclipse.jdt.core.dom.SimpleName; import org.eclipse.jdt.core.dom.VariableDeclarationFragment; public class Test { public static void main(String args[]){ ASTParser parser = ASTParser.newParser(AST.JLS3); //parser.setSource("int i = 9; \n int j;\n for(int k = 0; k < i; k++) {int ii =10;}; \n ArrayList<Integer> al = new ArrayList<Integer>();j=1000; ".toCharArray()); parser.setSource("int i = 9; \n int j;\n for {}; \n ArrayList<Integer> al = new ArrayList<Integer>();j=1000; ".toCharArray()); parser.setKind(ASTParser.K_STATEMENTS); parser.setStatementsRecovery(true); final Block block = (Block) parser.createAST(null); ASTNode parent = block.getParent(); while (parent != null && !(parent instanceof CompilationUnit)) { parent = parent.getParent(); } final CompilationUnit cu = (CompilationUnit) parent; cu.accept(new ASTVisitor() { Set names = new HashSet(); public boolean visit(VariableDeclarationFragment node) { SimpleName name = node.getName(); this.names.add(name.getIdentifier()); System.out.println("Declaration of '"+name+"' at line"+cu.getLineNumber(name.getStartPosition())); return false; // do not continue to avoid usage info } public boolean visit(SimpleName node) { if (this.names.contains(node.getIdentifier())) { System.out.println("Usage of '" + node + "' at line " + cu.getLineNumber(node.getStartPosition())); } return true; } }); } }
The AST currently has an EmptyStatement node corresponding to for{}; This is completely invalid and not even close to a usual 'for' syntax. What do you expect here?
(In reply to comment #1) > The AST currently has an EmptyStatement node corresponding to > for{}; > > This is completely invalid and not even close to a usual 'for' syntax. What do > you expect here? I understand that. But, is there any way we can recover the other statements. IMO, statement recovery is meant for that. But, with that also, AST is completely unusable. In case of errors (syntax/semantic), I expect ASTParser to recover all the remaining valid statements and cu.getProblems() will return all the problems(i.e errors).
This works fine if the code is wrapped into a compilation unit declaration. The parser options has to set the compiler source, target and compliance to 1.5 though. This would require further investigation as why the statement recovery doesn't return the same result with K_STATEMENTS and K_COMPILATION_UNIT.
So this works as you expect: import java.util.HashSet; import java.util.Map; import java.util.Set; import org.eclipse.jdt.core.JavaCore; import org.eclipse.jdt.core.dom.AST; import org.eclipse.jdt.core.dom.ASTParser; import org.eclipse.jdt.core.dom.ASTVisitor; import org.eclipse.jdt.core.dom.CompilationUnit; import org.eclipse.jdt.core.dom.SimpleName; import org.eclipse.jdt.core.dom.VariableDeclarationFragment; public class Test { public static void main(String args[]) { ASTParser parser = ASTParser.newParser(AST.JLS3); Map options = JavaCore.getOptions(); options.put(JavaCore.COMPILER_COMPLIANCE, JavaCore.VERSION_1_5); options.put(JavaCore.COMPILER_SOURCE, JavaCore.VERSION_1_5); options.put(JavaCore.COMPILER_CODEGEN_TARGET_PLATFORM, JavaCore.VERSION_1_5); parser.setSource("class X { public void foo() { int i = 9; \n int j;\n for {}; \n ArrayList<Integer> al = new ArrayList<Integer>();j=1000;}}" .toCharArray()); parser.setCompilerOptions(options); parser.setKind(ASTParser.K_COMPILATION_UNIT); parser.setStatementsRecovery(true); final CompilationUnit cu = (CompilationUnit) parser.createAST(null); cu.accept(new ASTVisitor() { Set names = new HashSet(); public boolean visit(VariableDeclarationFragment node) { SimpleName name = node.getName(); this.names.add(name.getIdentifier()); System.out.println("Declaration of '" + name + "' at line" + cu.getLineNumber(name.getStartPosition())); return false; // do not continue to avoid usage info } public boolean visit(SimpleName node) { if (this.names.contains(node.getIdentifier())) { System.out.println("Usage of '" + node + "' at line " + cu.getLineNumber(node.getStartPosition())); } return true; } }); } }
Ayushman, we should investigate why we have a difference between the two kinds: K_STATEMENTS and K_COMPILATION_UNIT. This might hide a more serious issue. Thanks.
I'll see what can be done as Ayushman is in vacations till M2 ships. Might have to be moved to 3.8M3.
(In reply to comment #1) > The AST currently has an EmptyStatement node corresponding to > for{}; In fact the recovery produces an empty statement for the ';' part of "for {};". There is no recovered statement at all corresponding to "for {}". I have a fix which returns the same number of statements using K_STATEMENTS, but it doesn't fix the missing recovered statement for the code "for {}". Testing the fix right now. Ayushman, we might work on trying to report a recovered statement for the bogus for loop.
Created attachment 203017 [details] Proposed fix + regression tests
Released for 3.8M2.
(In reply to comment #7) > Testing the fix right now. Ayushman, we might work on trying to report a > recovered statement for the bogus for loop. I opened bug 357139 for this.
Verified for 3.8M2 using build I20110912-0800
