Bug 235460 - [1.5][compiler] ClassCastException in JDT Compiler
Summary: [1.5][compiler] ClassCastException in JDT Compiler
Status: VERIFIED DUPLICATE of bug 231861
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows Vista
: P3 normal (vote)
Target Milestone: 3.4 RC2   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-03 16:32 EDT by Kay Huber CLA
Modified: 2008-09-16 10:29 EDT (History)
2 users (show)

See Also:


Attachments
Simple project to reproduce InternalCompiler error (3.54 KB, application/octet-stream)
2008-06-04 02:28 EDT, Kay Huber CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kay Huber CLA 2008-06-03 16:32:05 EDT
Building a project with Eclipse 3.4 RC1 using JDK6 on Windows Vista 32Bit (SP1) caused the following exception:

!ENTRY org.eclipse.core.resources 4 2 2008-06-03 22:22:24.803
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources".
!STACK 0
java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding cannot be cast to org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding
	at org.eclipse.jdt.internal.compiler.lookup.TypeBinding.isProvablyDistinct(TypeBinding.java:574)
	at org.eclipse.jdt.internal.compiler.ast.CastExpression.checkUnsafeCast(CastExpression.java:308)
	at org.eclipse.jdt.internal.compiler.ast.Expression.checkCastTypesCompatibility(Expression.java:486)
	at org.eclipse.jdt.internal.compiler.ast.CastExpression.resolveType(CastExpression.java:495)
	at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:186)
	at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:101)
	at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:233)
	at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:444)
	at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:191)
	at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1096)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1184)
	at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:535)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:743)
	at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
	at java.lang.Thread.run(Thread.java:619)
Comment 1 Olivier Thomann CLA 2008-06-03 17:22:19 EDT
Could you please provide a test case that is causing this problem?
Comment 2 Kay Huber CLA 2008-06-03 18:13:52 EDT
I'll need some time to do that. I found the line in the code, where the compiler struggles over, however, that line includes a number of classes of which the hierarchy seems to be very relevant. Thus, a number of classes is involved which I need to sort out first. If you have any hint on what I should particulary look for, then I could possibly create an example more quickly.
Comment 3 Philipe Mulet CLA 2008-06-03 19:27:22 EDT
The trace indicates presence of a down cast expression to a parameterized type (where the cast type is ill-formed due to bug in compiler).

The cast type is found as a binary, which could indicate a type from a library or any other type previously compiled in incremental build situation.

Normally, a binary parameterized type is not directly referenced as BinaryTypeBinding, since all accesses should have been resulting in either ParameterizedTypeBinding creation, or raw conversion. We seem to have a path where a direct BinaryTypeBinding gets surfaced, causing the stack trace to occur (i.e. failure would be expected).
Comment 4 Kay Huber CLA 2008-06-04 02:28:53 EDT
Created attachment 103509 [details]
Simple project to reproduce InternalCompiler error

Ok, I found a simple example. Unfortunately, it has the problem, that the error only occurs "occasionally" - but at least I know how to reproduce - I hope, it will be reproducible on your machines as well.

The class "InternalCompilerError_Main" is where the error occurs.
The "funny" part is, that I can "turn it on or off": If I open the InternalCompilerError_Main class in eclipse, add a space somewhere, press Save (Auto Building is turned on), the error disappears. If I do it again, it re-appears.
In my "real project", the error is always present.

Please tell me, if you're not able to reproduce with that project...
Comment 5 Philipe Mulet CLA 2008-06-04 07:06:47 EDT
Kay - could you try to reproduce with 3.4RC3 ? This could be a dup of bug 231861 (i.e. another symptom of this same bug).
Comment 6 Philipe Mulet CLA 2008-06-04 07:24:35 EDT
I could reproduce it with RC1, and not with RC3. The fix for bug 231861 addresses this symptom as well.

Added GenericTypeTest#test1338, which fails with jdt/core v_865, and passes with post RC2 versions.

*** This bug has been marked as a duplicate of bug 231861 ***
Comment 7 Philipe Mulet CLA 2008-06-04 07:27:24 EDT
Steps can be reproduced with batch compiler only:
1- compile first Derived_A.java and Derived_B.java
2- compile InternalCompilerError_Main.java against the classfiles produced in (1)

or in IDE, incrementally compile InternalCompilerError_Main (add a space and build)
Comment 8 Philipe Mulet CLA 2008-06-04 07:27:44 EDT
BTW - Kay: thanks for the quick testcase
Comment 9 Kay Huber CLA 2008-06-04 09:11:09 EDT
Can confirm: Compiler error has vanished with RC3 - thanks a lot!
Comment 10 Philipe Mulet CLA 2008-06-09 04:46:23 EDT
Regression test is actually GenericTypeTest#test1340
Comment 11 Frederic Fusier CLA 2008-09-16 10:29:16 EDT
Verified during 3.5M2 milestone verification process...