Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Refinements of value types based on Java primitives erase to Object when used as parameters of a method returning a generic #8756

Closed
scabug opened this issue Jul 28, 2014 · 5 comments
Closed

Refinements of value types based on Java primitives erase to Object when used as parameters of a method returning a generic #8756

scabug opened this issue Jul 28, 2014 · 5 comments
Assignees
@retronym
Milestone
2.12.0-M5

Comments

@scabug
Copy link

scabug commented Jul 28, 2014

So, this is fun:

First, a test file:

class Test {
  type T = Long {type Tag = Nothing}
  type S = String {type Tag = Nothing}
  def foo(t: T): List[Int] = Nil
  def bar(t: T): Int = 0
  def baz(s: S): List[Int] = Nil
}

Now the output of javap:

public class Test {
  public scala.collection.immutable.List<java.lang.Object> foo(java.lang.Object);
  public int bar(long);
  public scala.collection.immutable.List<java.lang.Object> baz(java.lang.String);
  public Test();
}

Note the bytecode parameter types of each method. Weird.

What's weirder is:

$ scalac -Xprint:erasure Test.scala
[[syntax trees at end of                   erasure]] // Test.scala
package <empty> {
  class Test extends Object {
    def <init>(): Test = {
      Test.super.<init>();
      ()
    };
    def foo(t: Long): List = immutable.this.Nil;
    def bar(t: Long): Int = 0;
    def baz(s: String): List = immutable.this.Nil
  }
}

Anyway, actually fixing this seems like it would break binary compatibility, so I don't think this can be fixed in 2.11.x.
@scabug
Copy link
Author

scabug commented Jul 28, 2014

Imported From: https://issues.scala-lang.org/browse/SI-8756?orig=1
Reporter: @clhodapp
Affected Versions: 2.11.2
See #4214

@scabug
Copy link
Author

scabug commented Jul 9, 2015

@SethTisue said:
This is certainly surprising, but it is necessary. For all the gory details, see #4214 and https://groups.google.com/d/msg/scala-internals/K2dELqajQbg/gV0tbjRHJ4UJ.

@scabug
Copy link
Author

scabug commented Jul 9, 2015

@paulp said (edited on Jul 9, 2015 8:50:30 PM UTC):
That's not the same problem. This is a fixable bug.

Play "one of these kids is not like the others" with the six bytecode signatures. That kid is the bug.

trait Bippy[A]

class Test {
  type T1 = Long
  type T2 = Long { type Tag = Nothing }

  def f1(t: T1): Bippy[Object] = ???
  def f2(t: T2): Bippy[Object] = ???
  def g1(t: T1): Int           = ???
  def g2(t: T2): Int           = ???
  def h1(t: T1): Object        = ???
  def h2(t: T2): Object        = ???

  // public Bippy<java.lang.Object> f1(long);
  // public Bippy<java.lang.Object> f2(java.lang.Object);
  // public int g1(long);
  // public int g2(long);
  // public java.lang.Object h1(long);
  // public java.lang.Object h2(long);
}

@scabug
Copy link
Author

scabug commented Jul 10, 2015

@SethTisue said:
I see now. Thanks for the correction. Reopening.

@scabug
Copy link
Author

scabug commented May 18, 2016

@retronym said:
scala/scala#5174

@scabug scabug closed this as completed May 18, 2016
@scabug scabug added this to the 2.12.0-M5 milestone Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@retronym retronym

Labels
None yet
Projects
None yet
Milestone
2.12.0-M5
Development

No branches or pull requests
2 participants
@retronym @scabug