Bug 100584 - [1.5][dom] NPE when selecting a faulty member type following a generic type reference
Summary: [1.5][dom] NPE when selecting a faulty member type following a generic type r...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.1 RC4   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-17 10:37 EDT by Maxime Daniel CLA
Modified: 2005-06-24 07:44 EDT (History)
4 users (show)

See Also:


Attachments
Philippe's fix for the type resolution (1.31 KB, patch)
2005-06-17 12:13 EDT, Maxime Daniel CLA
no flags Details | Diff
AST based regression test case (3.16 KB, patch)
2005-06-20 10:10 EDT, Maxime Daniel CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Maxime Daniel CLA 2005-06-17 10:37:06 EDT
Build id: I20050617-0010

Enter the following code into a fresh X class:
public class X<E> {
  public static class InnerClassA {
    static class InnerInnerClassA {
      public InnerInnerClassA() {
	System.out.println(X.InnerClass.InnerInnerClassA.this); // (a)
      }
    }
  }
}
Save and compile, then click into InnerClass on line (a). You get an internal
error with an NPE.

This comes from a dom type binding marked as having error returning null when
trying to get the declaration type binding. This only happens if the faulty type
 is a ParametrizedTypeBinding.
The following correction eliminates the problem (but I have not made complete
tests on it):

org.eclipse.jdt.core.dom.TypeBinding
public ITypeBinding getTypeDeclaration() {
  if (this.binding instanceof ParameterizedTypeBinding) {
    ITypeBinding attemptToResolve =
    this.resolver.getTypeBinding(((ParameterizedTypeBinding)this.binding).type);
    if (attemptToResolve != null) 
      return attemptToResolve;
  }
  return this;
}

This is only returning this when an error yields a null within the resolution.
Note that the existing code returns this for non parametrized types, be they
correct or erroneous. There might be a better solution that would trap the null
generation itself deeper into the resolution, but I haven't investigated further.
Comment 1 Maxime Daniel CLA 2005-06-17 10:49:24 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)
Comment 2 Maxime Daniel CLA 2005-06-17 12:11:11 EDT
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.
Comment 3 Maxime Daniel CLA 2005-06-17 12:13:18 EDT
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.
Comment 4 Philipe Mulet CLA 2005-06-17 12:16:33 EDT
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.
Comment 5 Philipe Mulet CLA 2005-06-17 12:22:39 EDT
Maxime - pls attach some regression test for it.
Comment 6 Dirk Baeumer CLA 2005-06-17 12:38:53 EDT
Fix looks save to me.

+1 since it can really affect editing experience.
Comment 7 Philipe Mulet CLA 2005-06-17 13:10:52 EDT
+1 as well. 

Just to late for RC3, plus it needs some testing (and writing a regression test).
Comment 8 Philipe Mulet CLA 2005-06-20 09:54:24 EDT
Candidating for RC4. Testing proved successful.
Comment 9 Maxime Daniel CLA 2005-06-20 10:10:48 EDT
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.
Comment 10 Philipe Mulet CLA 2005-06-21 11:14:59 EDT
Dirk - can you cast your vote ?
Comment 11 Philipe Mulet CLA 2005-06-21 11:15:21 EDT
Dani - can you cast your vote ?
Comment 12 Philipe Mulet CLA 2005-06-21 11:15:55 EDT
Kent - pls review the change
Comment 13 Philipe Mulet CLA 2005-06-21 11:16:14 EDT
Maxime - pls review the change
Comment 14 Philipe Mulet CLA 2005-06-21 11:24:02 EDT
Regression test is: ASTConverter15Test#test0192
Comment 15 Kent Johnson CLA 2005-06-21 11:39:58 EDT
Reviewed - straight forward change. Looks good.
Comment 16 Dirk Baeumer CLA 2005-06-21 11:55:26 EDT
+1 for RC4.
Comment 17 Dani Megert CLA 2005-06-21 11:59:38 EDT
+1 for 3.1 RC4
Comment 18 Philipe Mulet CLA 2005-06-21 14:00:56 EDT
Fixed
Comment 19 Maxime Daniel CLA 2005-06-24 07:22:41 EDT
Verified for Build id: I20050624-0010.
Comment 20 Olivier Thomann CLA 2005-06-24 07:44:23 EDT
Verified.