Community
Participate
Working Groups
BETA_JAVA7 I tried try-with-resources with a resource of a UnionType, which busted the AST: package tryresources; public class TryWithResources2 { void foo() { try (Object | Integer res= null) { } catch (Exception e) { } } } java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.resourceHasToBeAutoCloseable(ProblemReporter.java:6268) at org.eclipse.jdt.internal.compiler.ast.TryStatement.resolve(TryStatement.java:964) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:463) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:252) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:422) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1148) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1258) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:539) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1181) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:681) at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1183) at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:809) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:548) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:541) at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:484) at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:132) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:170) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
I'll fix it.
The test case below triggers the NPE against the compiler proper: public class X { void foo() { try (Object.Integer res = null) { } catch (Exception e) { } } } Basically, we are relying on the binding to supply the textual type name to use in the message and run into trouble when binding is null due to malformed code.
Created attachment 198305 [details] Proposed patch & tests
Released in BETA_JAVA7 branch.
I think we should also make sure we don't tag the method declaration as malformed. Only the variable declaration should be malformed. More specifically, it should be its type, but since the binding for the type is null anyway, tagging the variable declaration expression looks ok. Markus, any comment? I'll release a patch that tags the variable declaration expression as malformed and not the method declaration itself.
(In reply to comment #5) > I think we should also make sure we don't tag the method declaration as > malformed. Only the variable declaration should be malformed. I don't think we should touch that. I made a few experiments, and it looks like the current strategy is to always mark the MethodDeclaration as MALFORMED, no matter where in the body the syntax error appears. The only place where JDT UI frequently uses this property is in the SemanticHighlightingReconciler. Inside the declaration, the node that actually contains the syntax error is marked as RECOVERED, so clients that want to find the erroneous node can already do this now. > [..] the binding for the type is null anyway [..] That's only the case if bindings recovery is not enabled.
ok, then I'll revert the last commit.
Verified with v20110714-1300.
