Comment 1 Olivier Thomann 2005-06-17 14:42:06 EDT

If you could provide a complete test case even if it is big, it would be great.

Comment 2 Olivier Thomann 2005-06-17 14:49:18 EDT

Getting a test case might be the only way to get it fixed for 3.1.

Comment 3 Philipe Mulet 2005-06-21 09:41:36 EDT

Lowering severity. It cannot be a blocker without good steps to reproduce at
this stage.

Comment 4 Kent Johnson 2005-06-21 12:52:55 EDT

Found a case if a project has a large number of source files (> 1000).

In separate files & with AbstractImageBuilder.MAX_AT_ONCE set to 1.

class A  {
    Object foo(B b) { return b.i; }
}
class B  {
    I.InnerType i;
}
interface I {
	interface InnerType {}
}

Turn off auto-builds & touch both A.java & I.java, then manually build causes 
the following stack trace:

java.lang.ClassCastException: o.e.j.i.c.lookup.MemberTypeBinding
  at o.e.j.i.c.lookup.LookupEnvironment.createBinaryTypeFrom
(LookupEnvironment.java:476)
  at o.e.j.i.c.lookup.LookupEnvironment.createBinaryTypeFrom
(LookupEnvironment.java:465)
  at o.e.j.i.c.Compiler.accept(Compiler.java:190)
  at o.e.j.i.c.lookup.LookupEnvironment.askForType(LookupEnvironment.java:99)
  at o.e.j.i.c.lookup.UnresolvedReferenceBinding.resolve
(UnresolvedReferenceBinding.java:43)
  at o.e.j.i.c.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:85)
  at o.e.j.i.c.lookup.BinaryTypeBinding.resolveTypeFor
(BinaryTypeBinding.java:742)
  at o.e.j.i.c.lookup.BinaryTypeBinding.getField(BinaryTypeBinding.java:598)
  at o.e.j.i.c.lookup.Scope.findField(Scope.java:749)

Comment 5 Kent Johnson 2005-06-21 12:54:19 EDT

Fix is to LookupEnvironment.createBinaryType

public BinaryTypeBinding createBinaryTypeFrom(IBinaryType binaryType, 
PackageBinding packageBinding, boolean needFieldsAndMethods, AccessRestriction 
accessRestriction) {
	BinaryTypeBinding binaryBinding = new BinaryTypeBinding
(packageBinding, binaryType, this);
	
	// resolve any array bindings which reference the unresolvedType
	ReferenceBinding cachedType = packageBinding.getType0
(binaryBinding.compoundName[binaryBinding.compoundName.length - 1]);
	if (cachedType != null) { // update reference to unresolved binding 
after having read classfile (knows whether generic for raw conversion)
		if (cachedType instanceof UnresolvedReferenceBinding) {
			((UnresolvedReferenceBinding) 
cachedType).setResolvedType(binaryBinding, this);
		} else {
			if (cachedType.isBinaryBinding()) // sanity check... 
at this point the cache should ONLY contain unresolved types
				return (BinaryTypeBinding) cachedType;
			// it is possible with a large number of source files 
(exceeding AbstractImageBuilder.MAX_AT_ONCE) that a member type can be in the 
cache as an UnresolvedType,
			// but because its enclosingType is resolved while its 
created (call to BinaryTypeBinding constructor), its replaced with a source 
type
			return null;
		}
	}

	packageBinding.addType(binaryBinding);
	setAccessRestriction(binaryBinding, accessRestriction);
	binaryBinding.cachePartsFrom(binaryType, needFieldsAndMethods);
	return binaryBinding;
}

Comment 6 Kent Johnson 2005-06-21 12:55:58 EDT

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

Comment 7 Philipe Mulet 2005-06-21 13:31:23 EDT

Kent isolated it. This issue is a consequence of fix for bug 97108.
Basically, it needs to get fixed for RC4, since we may have issues on large
source workspaces, and it isn't 1.5 specific.

Kent - pls send patch to reporter to assess it fixes the problem; and attach a
CVS patch. 

Dirk - can you vote for it ?

Comment 8 Philipe Mulet 2005-06-21 13:31:42 EDT

Dani - can you vote for it ?

Comment 9 Kent Johnson 2005-06-21 13:42:27 EDT

Created attachment 23647 [details]
Patch to LookupEnvironment

Comment 10 Kent Johnson 2005-06-21 13:47:30 EDT

One question that will come up is whether its ok to answer null...

If you check the senders of createBinaryTypeFrom(), you'll see the return 
value is not used or is checked to see if its null.

We could change the return type of the method, but that would be more a change 
than is necessary at this point.

Comment 11 Tomasz Blachowicz / AMG.net 2005-06-21 14:25:54 EDT

I can confirm, that the project I tried to compile under Eclipse 3.1 is pretty 
big. It is about 4k classes in one source folder.

Comment 12 Dani Megert 2005-06-21 14:54:00 EDT

+1 for 3.1 RC4. Agree with Kent to keep the changes at a minimum at this point.

Comment 13 Dirk Baeumer 2005-06-21 17:29:19 EDT

+1 for RC4.

Comment 14 Gergely Nagy 2005-06-21 19:00:17 EDT

(In reply to comment #9)
> Created an attachment (id=23647) [edit]
> Patch to LookupEnvironment
> 
Great news: it does fix it!(at least, I run the patched JDT core with
self-hosting eclipse, and no stack trace in the Problems view with the same big
project).
Although I've already spent some time isolating&cleaning the test project before
I send you as a test case(not really obfuscating,just to calm down boss;),it
feels much better this way, thanks!

Comment 15 Tomasz Blachowicz / AMG.net 2005-06-22 04:42:45 EDT

I relplaced jdt.core jar in my Eclipse 3.1 RC3 with patched one sent by Kent to
me yesterday and it solved the problem. No more nasty errors in Java Builder.

Unfortunately I got another error "Error in JDT Core during AST creation". I'm
creating new issue in bugzilla right now. This new error refers other classes
than the previous one.

Comment 16 Philipe Mulet 2005-06-22 05:25:18 EDT

Kent - pls provide a regression test

Comment 17 Kent Johnson 2005-06-22 11:14:15 EDT

Added IncrementalTests testMemberTypeCollisionWithBinary().

Released change into HEAD for RC4.

Comment 18 Maxime Daniel 2005-06-24 04:56:26 EDT

Verified for Build id: I20050624-0010.
(Checked that the regression test case failed with I20050617-1618, raising a
problem similar to the problem which triggered the bug; checked that the same
regression test case passed with I20050624-0010.)

Comment 19 Olivier Thomann 2005-06-24 07:44:33 EDT

Verified.

Comment 20 Gergely Nagy 2011-06-04 10:09:08 EDT

Verified ages ago -sorry for the late update.