Summary: | [1.5][dom] NPE when selecting a faulty member type following a generic type reference | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Maxime Daniel <maxime_daniel> | ||||||
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | daniel_megert, dirk_baeumer, kent_johnson, maxime_daniel | ||||||
Version: | 3.1 | ||||||||
Target Milestone: | 3.1 RC4 | ||||||||
Hardware: | PC | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Maxime Daniel
2005-06-17 10:37:06 EDT
Forgot to precise: this only happens if the 'Toggle Mark Occurrences' option is active. Message is: An internal error occurred during: "Requesting Java AST from selection". Stack trace is: java.lang.NullPointerException at org.eclipse.jdt.internal.corext.dom.Bindings.equals(Bindings.java:88) at org.eclipse.jdt.internal.ui.search.OccurrencesFinder.match(OccurrencesFinder.java:239) at org.eclipse.jdt.internal.ui.search.OccurrencesFinder.visit(OccurrencesFinder.java:158) at org.eclipse.jdt.core.dom.QualifiedName.accept0(QualifiedName.java:166) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2450) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2497) at org.eclipse.jdt.core.dom.QualifiedName.accept0(QualifiedName.java:169) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2450) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2497) at org.eclipse.jdt.core.dom.ThisExpression.accept0(ThisExpression.java:138) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2450) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2520) at org.eclipse.jdt.core.dom.MethodInvocation.accept0(MethodInvocation.java:244) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2450) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2497) at org.eclipse.jdt.core.dom.ExpressionStatement.accept0(ExpressionStatement.java:143) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2450) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2520) at org.eclipse.jdt.core.dom.Block.accept0(Block.java:135) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2450) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2497) at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:501) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2450) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2520) at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:483) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2450) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2520) at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:483) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2450) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2520) at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:483) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2450) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2520) at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:299) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2450) at org.eclipse.jdt.internal.ui.search.OccurrencesFinder.perform(OccurrencesFinder.java:94) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.updateOccurrenceAnnotations(JavaEditor.java:2953) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$6.selectionChanged(JavaEditor.java:2982) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:173) at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$3.run(SelectionListenerWithASTManager.java:142) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) Philippe has investigated further: - the very fact that we build a ParameterizedTypeBinding that references a ProblemReferenceBinding is wrong; we should instead build a ProblemReferenceBinding and return it to the caller (see attached patch); - once this is fixed, the previous suggested fix is unneeded, since we never attempt to resolve a 'faulty' ParameterizedTypeBinding. Created attachment 23461 [details]
Philippe's fix for the type resolution
Build a ProblemReferenceBinding instead of a ParameterizedTypeBinding that
references a ProblemReferenceBinding in the context of the test case.
Scenario is quite annoying, especially given mark occurrences is enabled by default. Fix is quite trivial (check for error case before converting to param/raw), like it should always have been. Maxime - pls attach some regression test for it. Fix looks save to me. +1 since it can really affect editing experience. +1 as well. Just to late for RC3, plus it needs some testing (and writing a regression test). Candidating for RC4. Testing proved successful. Created attachment 23544 [details]
AST based regression test case
This test case specifically traps the case of a wrong binding construction for
the considered source fragment. Note that the correct behavior (construct a
correctly formed ProblemReferenceBinding) surfaces as a null at the test level.
Dirk - can you cast your vote ? Dani - can you cast your vote ? Kent - pls review the change Maxime - pls review the change Regression test is: ASTConverter15Test#test0192 Reviewed - straight forward change. Looks good. +1 for RC4. +1 for 3.1 RC4 Fixed Verified for Build id: I20050624-0010. Verified. |