Comment 1 Ismael Juma 2008-08-20 19:17:09 EDT

Created attachment 110502 [details]
Jar containing the class file for test.Map

Comment 2 Ismael Juma 2008-08-20 21:32:36 EDT

(In reply to comment #0)
> Description     Location        Resource        Path    Type
> Internal compiler error
> java.lang.NullPointerException
>         line 0  Test.java       java-scala-test/src/test2       Java Problem
>  
> Description     Location        Resource        Path    Type
> Internal compiler error
> java.lang.NullPointerException
>         line 0  Test.java       java-scala-test/src/test        Java Problem

Sorry, ignore the second error. I pasted it twice by mistake. Just the first one is relevant.

Comment 3 Olivier Thomann 2008-08-20 21:39:00 EDT

I am getting a slightly different stack trace.
java.lang.NullPointerException
at org.eclipse.jdt.internal.compiler.util.SimpleLookupTable.get(SimpleLookupTable.java:68)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createParameterizedType(LookupEnvironment.java:859)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1283)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:480)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:561)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:326)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:719)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:699)
at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:294)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:128)
at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:182)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:456)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:510)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:359)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:435)
at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:852)
at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:904)
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)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:149)
at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:102)
at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)

Comment 4 Olivier Thomann 2008-08-20 22:05:47 EDT

The signature of a method has an unexpected shape which leads to the NPE when  trying  to resolve the method.
The signature is: (TA;)Ltest/Map<TA;TB;>.Map$MapTo; and the expected one should be:
(TA;)Ltest/Map<TA;TB;>.MapTo;

The method org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.getMemberType(char[]) expects the member name not to contain its enclosing type name.

We should be more resilient, but this is also failing with javac once the source file is slightly modified.

Try to compile:
import test.Map;

public class X implements Map {
	public Map.MapTo $plus(Object o) {
  }
}

You get:
d:\tests_sources>javac X.java -classpath d:\Downloads\test.jar
X.java:3: cannot access test.Map$Map$MapTo
class file for test.Map$Map$MapTo not found
public class X implements Map {
       ^
X.java:4: $plus(java.lang.Object) in X cannot implement $plus(A) in test.Map; attempting to use incompatible return type
found   : test.Map.MapTo
required: test.Map$Map$MapTo
        public Map.MapTo $plus(Object o) {
                         ^
2 errors

which means that the decoding of the member type also fails since it is looking for a type Map$Map$MapTo.

Comment 5 Ismael Juma 2008-08-20 22:11:32 EDT

Thanks for looking into this.

Is it right to say that there's a bug in the bytecode generated by the Scala compiler then?

Comment 6 Olivier Thomann 2008-08-21 12:54:19 EDT

I would say yes. The signature is boggus, but we could be more resilient than failing with a NPE.
So both sides need to be fixed: scala compiler and our compiler to "properly" reject such boggus signatures.

Comment 7 Ismael Juma 2008-08-21 14:29:35 EDT

Makes sense, I filed a bug in the Scala bug tracker too (in case someone else hits this):

http://lampsvn.epfl.ch/trac/scala/ticket/1263

Comment 8 Kent Johnson 2008-09-10 15:05:26 EDT

Created attachment 112240 [details]
Proposed patch

With this patch, the supplied testcase fails the build with an error:

The class file Map<A,B> contains a signature '(TA;)Ltest/Map<TA;TB;>.Map$MapTo;' ill-formed at position 23

The error message is our existing CorruptedSignature message.

If we believe this problem is more common then we can make a specific one for corrupted member type signatures.

Ok?

Comment 9 Ismael Juma 2008-09-10 16:42:48 EDT

I am not sure if the question was directed at me, but I'm happy with the proposed error.

Comment 10 Kent Johnson 2008-09-10 16:57:23 EDT

It was directed at anyone who is listening ;)

Comment 11 Kent Johnson 2008-10-03 14:10:55 EDT

Fix released into 3.5M3

To verify:

1. Add test.jar attached to the build path.
2. Create the following file:

import test.Map;
public class Test {}

3. Verify that the error "The class file Map<A,B> contains a signature '(TA;)Ltest/Map<TA;TB;>.Map$MapTo;' ill-formed at position 23" appears and no stack trace is dumped

Comment 12 Kent Johnson 2008-10-07 14:39:49 EDT

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

Comment 13 David Audel 2008-10-27 08:37:15 EDT

Verified for 3.5M3 using I20081026-2000 build.

Comment 14 Olivier Thomann 2009-01-28 11:46:39 EST

Created attachment 124046 [details]
Patch for 3.4 maintenance branch

Comment 15 Philipe Mulet 2009-01-28 12:08:55 EST

+1 for 3.4.2

Comment 16 Olivier Thomann 2009-01-28 12:19:20 EST

Reopen to close for 3.4.2.

Comment 17 Olivier Thomann 2009-01-28 12:19:44 EST

Released for 3.4.2.

Comment 18 Frederic Fusier 2009-02-03 16:47:05 EST

Unfortunately, we missed to backport this fix into 3.4.2 stream.
So, change the target to 3.5M3 and set as verified in this stream...

Comment 19 Olivier Thomann 2009-02-03 16:58:29 EST

This is backported to 3.4.2.
The map file is updated with the corresponding version.

Comment 20 Frederic Fusier 2009-02-03 17:06:20 EST

(In reply to comment #19)
> This is backported to 3.4.2.
> The map file is updated with the corresponding version.
> 
That's right. Sorry for the confusion => I put back the 3.4.2 target and I'll verify it when tomorrow's maintenance build will be available

Comment 21 Olivier Thomann 2009-02-03 17:25:37 EST

Reopening to close as RESOLVED/FIXED and not VERIFIED/FIXED.

Comment 22 Olivier Thomann 2009-02-03 17:25:54 EST

Fixed.

Comment 23 Frederic Fusier 2009-02-04 03:42:00 EST

(In reply to comment #21)
> Reopening to close as RESOLVED/FIXED and not VERIFIED/FIXED.
> 
FYI, it was not necessary to reopen the bug as I set the Status Whiteboard to 'To be verified for 3.4.2.' (see JDT/Core bug life cycle step 2.1 in the FAQ)...

Comment 24 Olivier Thomann 2009-02-05 09:09:09 EST

Verified for 3.4.2 using M20090204-1400.

Comment 25 Olivier Thomann 2009-02-24 13:59:59 EST

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