Bug 230026

Summary: [1.5][compiler] CCE during static import resolution with parameterized type
Product: [Eclipse Project] JDT Reporter: Brian Miller <Brian.Miller>
Component: CoreAssignee: Kent Johnson <kent_johnson>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: martinae, Olivier_Thomann, philippe_mulet
Version: 3.4   
Target Milestone: 3.4 RC1   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
workspace
none
Regression test
none
Possible patch
none
Proposed patch
none
New proposed patch and testcases
none
New proposed patch and testcase
none
Released patch and testcases none

Description Brian Miller CLA 2008-05-02 15:45:11 EDT
Created attachment 98498 [details]
workspace

3.4 M6

Build ID: I20080330-1350

Steps To Reproduce:
1. Unzip the attached workspace and open it in Eclipse.
2. Show the error log view.
3. Open Java type Crash, if it isn't already open.
4. Click the mouse repeatedly on Crash's editor.  See this in the error log:

java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding cannot be cast to org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding
at org.eclipse.jdt.internal.compiler.lookup.Scope.findField(Scope.java:857)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleStaticImport(CompilationUnitScope.java:526)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:509)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveSingleImport(CompilationUnitScope.java:713)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2428)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2169)
at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding(SingleTypeReference.java:44)
at org.eclipse.jdt.internal.compiler.ast.TypeReference.internalResolveType(TypeReference.java:130)
at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:201)
at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveTypeArgument(TypeReference.java:209)
at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.internalResolveType(ParameterizedSingleTypeReference.java:176)
at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.resolveType(ParameterizedSingleTypeReference.java:278)
at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:179)
at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1159)
at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:859)
at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:1002)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:290)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:185)
at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:662)
at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:375)
at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:781)
at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:847)
at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:182)
at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:243)
at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:190)
at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:709)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:769)
at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1224)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:124)
Comment 1 Olivier Thomann CLA 2008-05-02 21:58:34 EDT
Reproduced with 3.4M7.
Reduced test case in org.eclipse.jdt.core.tests.compiler.regression.StaticImportTest#test065
See attached patch.

Fails with:
Internal compiler error
java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding cannot be cast to org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding
	at org.eclipse.jdt.internal.compiler.lookup.Scope.findField(Scope.java:863)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleStaticImport(CompilationUnitScope.java:526)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:509)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveSingleImport(CompilationUnitScope.java:713)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2434)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2175)
	at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding(SingleTypeReference.java:44)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.internalResolveType(TypeReference.java:130)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:201)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveTypeArgument(TypeReference.java:209)
	at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.internalResolveType(ParameterizedSingleTypeReference.java:176)
	at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.resolveType(ParameterizedSingleTypeReference.java:278)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:179)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1164)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:864)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:1007)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:290)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:185)
	at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:713)
	at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:376)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:420)
	at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:3543)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1645)
	at org.eclipse.jdt.internal.compiler.batch.Main.main(Main.java:1358)
Comment 2 Olivier Thomann CLA 2008-05-02 21:59:04 EDT
Created attachment 98518 [details]
Regression test
Comment 3 Kent Johnson CLA 2008-05-05 14:48:54 EDT
This bug exists in 3.3.2, as well as 3.4M7
Comment 4 Philipe Mulet CLA 2008-05-06 11:52:01 EDT
Created attachment 98869 [details]
Possible patch

I suspect a similar issue could arise with static import for a method.
Comment 5 Philipe Mulet CLA 2008-05-06 11:52:36 EDT
+1 for 3.3.x backport once avail
Comment 6 Kent Johnson CLA 2008-05-06 13:58:12 EDT
Created attachment 98898 [details]
Proposed patch
Comment 7 Philipe Mulet CLA 2008-05-06 15:57:09 EDT
I think it does the trick.

I would also equip CompilationUnitScope#findStaticMethod just in case (since it contains the offending pattern as well). I understand that when called in sequence, it doesn't need it, but it should be possible to call it independantly as well.
Comment 8 Kent Johnson CLA 2008-05-08 13:07:37 EDT
Created attachment 99331 [details]
New proposed patch and testcases

Philippe - see additional tests for why this patch is more involved.
Comment 9 Philipe Mulet CLA 2008-05-09 05:10:08 EDT
I would change:
ParameterizedTypeBinding
	void initializeForStaticImports() {
		this.type.initializeForStaticImports();
	}

Suggestions: 
- Instead of setting the new tagbits in setField/setMethod, I would position them in buildFields/buildMethods so it is all contained in one place.
- Instead of using tagbits, you could use special empty collections: Binding.UNITIALIZED_FIELDS ?

Overall, the fix looks safe.
Comment 10 Kent Johnson CLA 2008-05-12 09:51:23 EDT
Created attachment 99703 [details]
New proposed patch and testcase
Comment 11 Kent Johnson CLA 2008-05-12 13:21:41 EDT
Created attachment 99752 [details]
Released patch and testcases

Released for 3.4RC1

Added StaticImportTest test65-69
Comment 12 Kent Johnson CLA 2008-05-12 13:24:57 EDT
Released for 3.4RC1
Comment 13 Maxime Daniel CLA 2008-05-14 02:57:57 EDT
Verified for 3.4 RC1 using build I20080513-2000.

Waiting for backport decision.