Comment 1 Philipe Mulet 2004-05-19 13:07:00 EDT

Cannot reproduce. There must be other types involved in it. Is it an 
incremental recompilation ?

Comment 2 Philipe Mulet 2004-05-19 18:14:09 EDT

Please reopen once reproducing steps are available.

Comment 3 Brian Skaarup 2004-05-24 03:59:29 EDT

If I do this (I have had a colleuge to do the same, resulting in the same error):
Unpack M9 to d:\M9-1
run eclipse.exe (using j2se 1.4.2_04)
Add the cheetah update 0.0.5
Add new java project
Add new class V extending Vector in default package
Add method addAll
Added the j2sdk1.5.0 JRE in Preferences
Select the 1.5 JRE & click OK (rebuilds all)
Change compliance level to 1.5 in Preferences and press OK
Undefined base type: .

Swithcing back to 1.4 compliance, the error disappears

Comment 4 Philipe Mulet 2004-05-24 07:54:31 EDT

Cannot reproduce still. It works just fine for me, issuing the following 
warning:

----------
1. WARNING in V.java (at line 5)
	return super.addAll(arg0);
	       ^^^^^^^^^^^^^^^^^^
Unsafe type operation: Should not invoke the method addAll(Collection<? 
extends E>) of raw type Vector. References to generic type Vector<E> should be 
parameterized
----------
1 problem (1 warning)

I can only bet this is a bug in the JDK1.5 libraries themselves. I am using 
beta2-b50, which doesn't seem to expose this issue any longer. The trace 
indicates that an inconsistent signature in some binaries.

Comment 5 Philipe Mulet 2004-05-24 08:45:31 EDT

Replaced the Error exception with generation of a problem requiring to abort 
instead.

Comment 6 Brian Skaarup 2004-05-24 08:54:51 EDT

beta2-b50?
Where did you get it?
I only have build 1.5.0-beta-b32c

Comment 7 Philipe Mulet 2004-05-24 09:10:54 EDT

From private channels in IBM. You need to interact with Sun to gain access to 
it.

Comment 8 Philipe Mulet 2004-05-24 19:30:52 EDT

Reproduced using beta1. Indeed beta1 contains corrupted binary signatures, 
likely supported by javac in there. 

Offending classfile: java.util.AbstractList$ListItr has a signature attribute:

Ljava/util/AbstractList<TE;>;.Ljava/util/AbstractList$Itr;Ljava/util/ListIterat
or<TE;>;

which should instead read (as of beta2):
Ljava/util/AbstractList<TE;>.Itr;Ljava/util/ListIterator<TE;>;

Closing as invalid. We cannot support corrupted binaries.

Comment 9 Philipe Mulet 2004-05-24 19:35:18 EDT

One more question though. Why do we bother decoding the member type ListItr 
where it is only internally used ? It looks like this scenario shouldn't 
notice the broken signature, as no need to eagerly resolve the member types.

Comment 10 Philipe Mulet 2004-05-24 19:36:59 EDT

Kent - pls investigate eager resolution of member types. We request too much. 
I tried javac beta2 against lib beta1, and it doesn't care about broken 
signature, when turning into verbose mode, it appears it doesn't load the 
member type, as I would expect we also did.

Comment 11 Philipe Mulet 2004-05-25 05:26:46 EDT

I did some measurement, and we indeed load 6 more types than javac, which is 
~50% more than we need.

LOADED BINARIES BY ECLIPSE (sorted by type name)
SAME AS JAVAC:
[reading    java/util/AbstractCollection.class]
[reading    java/util/AbstractList.class]
[reading    java/util/Collection.class]
[reading    java/lang/Cloneable.class]
[reading    java/lang/Iterable.class]
[reading    java/util/Iterator.class]
[reading    java/util/List.class]
[reading    java/util/ListIterator.class]
[reading    java/lang/Object.class]
[reading    java/util/RandomAccess.class]
[reading    java/io/Serializable.class]
[reading    java/lang/String.class]
[reading    java/util/Vector.class]

EXTRA FILES JAVAC DOESN'T NEED
[reading    java/util/AbstractList$Itr.class]
[reading    java/util/AbstractList$ListItr.class]
[reading    java/util/Enumeration.class]
[reading    java/io/IOException.class]
[reading    java/io/ObjectOutputStream.class]
[reading    java/lang/Throwable.class]

Re-tagging for RC1 as this could benefit to our memory profile.

Comment 12 Philipe Mulet 2004-05-25 06:37:28 EDT

In verbose mode, by changing Compiler#accept(IBinaryType) as below, I was able 
to trace the load of offending binaries.

public void accept(IBinaryType binaryType, PackageBinding packageBinding) {
  if (options.verbose) {
    System.out.println(
      Util.bind(
        "compilation.loadBinary" , //$NON-NLS-1$
        new String[] {
          new String(binaryType.getName())}));
    new Exception("TRACE BINARY").printStackTrace(System.out);
    System.out.println();
   }
  lookupEnvironment.createBinaryTypeFrom(binaryType, packageBinding);
}

Comment 13 Philipe Mulet 2004-05-25 06:39:18 EDT

Offending invocations are:
ClassScope#checkForInheritedMemberTypes

Comment 14 Philipe Mulet 2004-05-25 06:43:39 EDT

Previous comment got truncated.

Offending invocations are:
ClassScope#checkForInheritedMemberTypes
   it asks for memberTypes() just to check whether there is any. 
   --> replacing with non populating (new) predicate #hasMemberTypes()
ReferenceBinding#getMemberType(char[])
   asks for memberTypes(), without checking for name match, and thus 
   triggers all resolution (even though in this case, no name match exists).
   --> override default implementation to do name check first.

+ flow analysis is eagerly loading Throwable, where it should avoid doing so 
until some exception type hierarchy is resolved.

Comment 15 Philipe Mulet 2004-05-25 09:37:55 EDT

Released changed for making binary member type resolution more lazy.
Also changed flow analysis to avoid eagerly referencing Throwable.

Note: the fix has nothing to do with Cheetah itself. It is only exposed by the 
fact one of the unnecessary loaded type had issues which caused Cheetah to 
diagnose an error in it.

Fixed in 3.0.

Comment 16 Philipe Mulet 2004-05-25 09:51:01 EDT

Added regression test: NegativeTest#test429.
Also verifiable using batch compiler with -verbose command line option to see 
exactly the binaries loaded during compilation.

Comment 17 Olivier Thomann 2004-05-28 16:08:55 EDT

Verified that the list of .class files requested during compilation is:

[reading    java/util/Vector.class]
[reading    java/util/AbstractList.class]
[reading    java/util/AbstractCollection.class]
[reading    java/lang/Object.class]
[reading    java/util/Collection.class]
[reading    java/lang/Iterable.class]
[reading    java/util/List.class]
[reading    java/io/Serializable.class]
[reading    java/lang/Cloneable.class]
[reading    java/util/RandomAccess.class]

Verified in 200405281200