Incorrect bytecode generated for StringBuilder.max

[scabug]

=== Background ===
While trying to weave a simple AspectJ aspect is a Scala compiler jar,
we got a puzzling error that fails the AspectJ weaver if we use
Scala version 2.8.1 or 2.9.0-SNAPSHOT, but not 2.8.0.
Upon closer inspection (see below) there appears to be a problem
due to inconsistent bytecode generated by the Scala compiler.
This not only fails with AspectJ, but also
crashes the Eclipse compiler in a plain (non-AspectJ) Java project.

Here is the analysis based on input from AspectJ project lead Andy Clement.

The issue is with StringBuilder.max (with 2.8.1)

=== What steps will reproduce the problem ? ===
Here is the bytecode generated by the Scala compiler:

public java.lang.Object max(scala.math.Ordering);
 Code:
  Stack=2, Locals=2, Args_size=2
  0:   aload_0
  1:   aload_1
  2:   invokestatic    SI-1024; //Method
scala/collection/TraversableOnce$$class.max:(Lscala/collection/TraversableOnce;Lscala/math/Ordering;)Ljava/lang/Object;
  5:   areturn
 Signature: length = 0x2
  03 FFFFFFFD

So it calls another method then finishes with an ARETURN (i.e.
returning an object, not a primitive). Now it is generic so we can
lookup the original signature using that attribute, the generic
signature is:

 <B:Ljava/lang/Object;>(Lscala/math/Ordering<TB;>;)C;

and that says that the method returns a char (the trailing C), so it
should have been declared 'char max(Ordering)' and finish with an
IRETURN.

Now, the compiler may be being clever and looking for the boxing to a
Character, but it seems odd that the generic signature disagrees
with the bytecode signature in that way.

In Scala 2.8.0 it was not a generic method so there is no mismatch in
signatures.

=== Seeing the problem without involving AspectJ ===
If you want to see the Eclipse compiler crashing, create a pure java project,
give it a dependency on the 2.8.1 scala library then try to compile
this:

import scala.collection.mutable.StringBuilder;

public class CC {
       public void m() {
               StringBuilder sb = new StringBuilder();
       }
 }

Eclipse throws up an error message (an Internal compiler error)

Internal compiler error: java.lang.ClassCastException: 
org.eclipse.jdt.internal.compiler.lookup.BaseTypeBinding cannot be cast to 
org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding at 
org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.initializeTypeVariable(BinaryTypeBinding.java:944)	CC.java	/scala-library-bug/src/bug	
line 0

I can attach the project if you wish, but as you can see,
there isn't much needed to get the Eclipse compiler to crash.

=== What versions of the following are you using? ===

• Scala: 2.8.1 and 2.9.0-SNAPSHOT (2.8.0 works fine)
• Java: 1.6.0_22
• Operating system: Mac Snow Leopard

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-4214?orig=1
Reporter: Ramnivas Laddad (ramnivas)

[scabug]

@paulp said:
This is extremely helpful, thank you. I have made alterations such that syntactically invalid signatures can no longer be geneerated, but this is what I was afraid was still out there. This is important, but right now I don't know how fast I'll be able to get to it.

(See also #4067 which I was hoping this would be a duplicate of, but is not.)

[scabug]

@axel22 said:
Paul, can I assign this to you?

[scabug]

@paulp said:
Assignment assigned.

[scabug]

@SethTisue said:
for whatever it's worth, I'm hitting this issue trying to use ENSIME with Scala 2.8.1

[scabug]

@odersky said:
The wrong signature is generated for a method that forwards to a trait implementation. Easiest fix would be to leave out the Scala signatures for trait forwarders. You'll get them in any case on the trait interface itself.

[scabug]

@odersky said:
(In r24319) Attempt to fix #4214 by avoiding signature generation for mixed in and bridge methods.

[scabug]

@odersky said:
r24319 avoids signature generation for bridge methods and mixed in methods. I ran out of time, so could not verify that it does address the problem. If there are unintended side effects, please revert.

[scabug]

@paulp said:
(In r24344) Reversion of r24319 for causing #4291. Test case to fence out #4291
in future attempts. Closes #4291, references #4214, no review.

[scabug]

@SethTisue said:
another Ensime user is affected too, see https://github.com/aemoncannon/ensime/issues/#issue/138

[scabug]

@paulp said:
(In r24363) Another lap around the track with generic signatures.
At the root of the issue reported in #4214 is our old friend
(fondly remembered from the days of primitive equality)
boxed/primitive unification.

  trait T[A] {
    def f(): A
  }
  // the generic signature spec doesn't allow for parameterizing
  // on primitive types, so this cannot remain Char.  However
  // translating it to Character, as was done, also has issues.
  class C extends T[Char] {
    def f(): Char = 'a'
  }

  // Note that neither of the signatures for f, the implementation
  // or the bridge method, matches the type parameter.
  Generic interfaces in class:
    T<java.lang.Character>
  Generic signatures:
    public char C.f()
    public java.lang.Object C.f()

After this commit, primitive type parameters are translated into
Object instead of the boxed type. It was martin's idea, so no review.
Closes #4214.

[scabug]

Ramnivas Laddad (ramnivas) said:
Thanks. Is there a snapshot version with this fix I can try? The latest one at http://scala-tools.org/repo-snapshots seems to be from Feb 27.

[scabug]

@paulp said:
Replying to [comment:15 ramnivas]:

Thanks. Is there a snapshot version with this fix I can try? The latest one at http://scala-tools.org/repo-snapshots seems to be from Feb 27.

Yeah, I don't know what's going on with the maven deploy failing but I think I woke up the appropriate parties today. You can wait until that's fixed or download a nightly from http://www.scala-lang.org/node/212/distributions .

[scabug]

@paulp said:
Replying to [comment:15 ramnivas]:

Thanks. Is there a snapshot version with this fix I can try? The latest one at http://scala-tools.org/repo-snapshots seems to be from Feb 27.

FYI now there are up to date snapshots, and any followup report positive or negative would be useful.

[scabug]

Ramnivas Laddad (ramnivas) said:
I tried this a couple of days back with my original code (weaving AspectJ into Scala). First, I met with an issue that is now resolved in AspectJ nightly. Now I still see a VerifyError in the same place (class: scala/collection/mutable/StringBuilder, method: minBy signature: (Lscala/Function1;Lscala/math/Ordering;)Ljava/lang/Object;) Expecting to find integer on stack). However, I no longer see Eclipse compiler crash as I reported in the original error. Currently, I am working with the AspectJ lead to figure out what's causing that error and it may very well turn out to be an AspectJ issue. I will report back as soon as we have some lead.