Comment 1 Philipe Mulet 2006-07-21 11:03:24 EDT

Please give a try to our 3.2.1 preview posted at:
http://www.eclipse.org/jdt/core/r3.2/index.php#UPDATES

If unlucky, then we will need steps to reproduce so as to address it.

Comment 2 Steve Canfield 2006-07-28 15:41:15 EDT

*** Bug 152202 has been marked as a duplicate of this bug. ***

Comment 3 Steve Canfield 2006-07-30 18:13:47 EDT

(In reply to comment #1)
> Please give a try to our 3.2.1 preview posted at:
> http://www.eclipse.org/jdt/core/r3.2/index.php#UPDATES

I put the org.eclipse.jdt.core_3.2.1.jar and removed my old org.eclipse.jdt.core jar, started Eclipse and did a clean and build of everything. The problem remains.

I'm not sure what other information I can send you. I'm unable to send the source code. I can tell you that the particular file has a bunch of generics in it (I didn't write it).

Comment 4 Will Dickson 2006-08-02 10:09:10 EDT

I've replaced the 3.2.0 org.eclipse.jdt.core.jar with the 3.2.1 preview. Same problem, but slightly different line nos on the stack trace:

Internal compiler error
java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding
	at org.eclipse.jdt.internal.compiler.lookup.Scope.findMemberType(Scope.java:959)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2331)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2052)
	at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.internalResolveType(ParameterizedSingleTypeReference.java:99)
	at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.resolveType(ParameterizedSingleTypeReference.java:209)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:110)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1083)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperInterfaces(ClassScope.java:883)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:929)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:289)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:198)
	at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:383)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:300)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:213)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:237)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:59)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:249)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:169)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:603)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:167)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:230)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:233)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:252)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:285)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:145)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:208)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)



I'll try to build an anonymised demonstration that I can upload.

Comment 5 Will Dickson 2006-08-02 11:24:11 EDT

Created attachment 47231 [details]
Example code which triggers the bug

The attached project contains code which triggers this bug. The bug appears to be sensitive to package names or structure: if it won't come out to play, try refactor|rename package on the two packages. The bug seems to be a bit of a Schrodinbug so you might have to play around a little. It might be important whether or not the package containing ResultFilter is the superpackage of the one containing NameRF.

Comment 6 Will Dickson 2006-08-02 11:29:47 EDT

In the example code, ResultFilter contains an enum. FWIW, I managed to avoid the bug by promoting this enum to its own file and changing NameRF accordingly: the rest of the project didn't compile due to ricochets (correct compiler behaviour) but NameRF itself did. Don't know if this helps.

Comment 7 Will Dickson 2006-08-02 11:33:29 EDT

Re comment 6: for "... avoid the bug ..." read "... avoid the bug for the corresponding code in the real project...".

Comment 8 Steve Canfield 2006-08-02 16:53:13 EDT

(In reply to comment #6)
> In the example code, ResultFilter contains an enum. FWIW, I managed to avoid
> the bug by promoting this enum to its own file and changing NameRF accordingly:
> the rest of the project didn't compile due to ricochets (correct compiler
> behaviour) but NameRF itself did. Don't know if this helps.
> 

Thanks for the update Will. My problem class also had a bunch of inner generic classes. I refactored these to be top level classes rather than inner classes and I can build again. I really hate to do this because it's so ugly, but it does work.

Comment 9 Maxime Daniel 2006-08-03 05:44:38 EDT

Reproduced with the R3_2_maintenance. Will investigate.

Comment 10 Maxime Daniel 2006-08-03 09:35:03 EDT

Added ReconcilerTests#testBug151410[ac] (a and b not being active).
This shows that the static import somehow triggers the use of a ParameterizedTypeBinding where the hierarchy resolution would never expect one.

The following code - crafted after the example of comment #5 - passes and might be less damaging a workaround:

package ccs.jdtbug.filters;
// import static ccs.jdtbug.ResultFilter.Action.*;
import ccs.jdtbug.*;
public class NameRF implements ResultFilter<String>
{
public Action getAction(String in, int ntotal, int naccept)
{
	return Action.YES; // qualified
}
}

Comment 11 Frederic Fusier 2006-08-03 13:40:48 EDT

I finally found that this bug was already fixed in 3.3 stream.

I've reverted changes in ReconcilerTests and add a specific one in GenericTypeTest#test1021c()

I've also updated the 3.2.1 preview posted at:
http://www.eclipse.org/jdt/core/r3.2/index.php#UPDATES

Please try again with this new version and let us know if it definitely fixes your problem, thanks


*** This bug has been marked as a duplicate of 149376 ***

Comment 12 Will Dickson 2006-08-08 19:25:20 EDT

OK, that seems to work. Thanks, guys.