Bug 31985 - NPE searching non-qualified and case insensitive type ref
Summary: NPE searching non-qualified and case insensitive type ref
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.1 RC1   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-02-17 05:18 EST by Jerome Lanneluc CLA
Modified: 2003-02-25 06:29 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jerome Lanneluc CLA 2003-02-17 05:18:19 EST
Build 20030214

Searching for type reference to 'Throwable' in jdt.core with in case 
insensitive mode throws the following NPE:

Caused by: java.lang.NullPointerException
        at 
org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypeFor
(SourceTypeBinding.java:763)
        at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.getField
(SourceTypeBinding.java:491)
        at org.eclipse.jdt.internal.compiler.lookup.Scope.findField
(Scope.java:196)
        at org.eclipse.jdt.internal.compiler.lookup.MethodScope.findField
(MethodScope.java:331)
        at org.eclipse.jdt.internal.compiler.lookup.BlockScope.getBinding
(BlockScope.java:445)
        at 
org.eclipse.jdt.internal.compiler.ast.QualifiedNameReference.resolveType
(QualifiedNameReference.java:720)
        at org.eclipse.jdt.internal.compiler.ast.ExplicitConstructorCall.resolve
(ExplicitConstructorCall.java:245)
        at 
org.eclipse.jdt.internal.compiler.ast.ConstructorDeclaration.resolveStatements
(ConstructorDeclaration.java:392)
        at 
org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve
(AbstractMethodDeclaration.java:309)
        at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve
(TypeDeclaration.java:789)
        at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve
(TypeDeclaration.java:830)
        at 
org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve
(CompilationUnitDeclaration.java:259)
        at org.eclipse.jdt.internal.core.search.matching.MatchLocator2.process
(MatchLocator2.java:950)
        at 
org.eclipse.jdt.internal.core.search.matching.MatchLocator2.locateMatches
(MatchLocator2.java:663)
        at 
org.eclipse.jdt.internal.core.search.matching.MatchLocator2.locateMatches
(MatchLocator2.java:835)
        at org.eclipse.jdt.core.search.SearchEngine.search
(SearchEngine.java:470)
        at org.eclipse.jdt.internal.ui.search.JavaSearchOperation.execute
(JavaSearchOperation.java:86)
        at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run
(WorkspaceModifyOperation.java:65)
        at org.eclipse.core.internal.resources.Workspace.run
(Workspace.java:1588)
        at org.eclipse.ui.actions.WorkspaceModifyOperation.run
(WorkspaceModifyOperation.java:79)
        at org.eclipse.jface.operation.ModalContext$ModalContextThread.run
(ModalContext.java:95)
Comment 1 Philipe Mulet CLA 2003-02-17 05:52:26 EST
Did it work with MatchLocator (1) ?
Comment 2 Jerome Lanneluc CLA 2003-02-17 06:56:18 EST
Yes, it used to work with MatchLocator (1)
Comment 3 Jerome Lanneluc CLA 2003-02-17 11:15:33 EST
It is failing because the cu being processed needs to be resolved (because of a 
single name reference which is a potential match), but it needs a cu that was 
initialy in the queue but that didn't need resolve.

Now marking type reference pattern and field reference pattern as always 
needing resolve.

Added regression test JavaSearchTests.testTypeReference3()
Comment 4 David Audel CLA 2003-02-25 06:29:24 EST
Verified.