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.

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

Specialization not visiting local methods - is there a fundamental reason for this? #7344

Closed
scabug opened this issue Apr 8, 2013 · 5 comments
Closed
Assignees
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Apr 8, 2013

$ cat spec-local.scala 
object Test {
  def meth = {
    def specMe[@specialized(Int) T](t: T) = ???
  }
}

$ ../build/quick/bin/scalac -Xprint:specialize spec-local.scala 
[[syntax trees at end of                specialize]] // spec-local.scala
package <empty> {
  object Test extends Object {
    def <init>(): Test.type = {
      Test.super.<init>();
      ()
    };
    def meth(): Unit = {
      // specMe doesn't deserve specialization? :(
      def specMe[@specialized(scala.Int) T >: Nothing <: Any](t: T): Nothing = scala.this.Predef.???();
      ()
    }
  }
}

A question is whether this was overlooked or is there a serious reason that specialization does not visit local methods. Btw, this bit us while working on https://github.com/nicolasstucki/specialized/.

@scabug
Copy link
Author

@scabug scabug commented Apr 8, 2013

Imported From: https://issues.scala-lang.org/browse/SI-7344?orig=1
Reporter: @VladUreche
Affected Versions: 2.10.0
Other Milestones: 2.11.0-M4

@scabug
Copy link
Author

@scabug scabug commented May 27, 2013

@paulp said:
This was just brought up by rex kerr as well. I feel safe in saying there's no reason not to specialize local methods; quite the opposite, they should be prioritized because the limited visibility means they won't be subject to most of the problems which plague specialization.

@scabug
Copy link
Author

@scabug scabug commented Jun 12, 2013

@VladUreche said:
A little digging into this bug shows there's an undocumented assumption in specialization: normalized members (methods whose type parameters are specialized) should always belong to classes. This assumption is visible in the info transformer, which only matches ClassInfoTypes and in the tree transformer which only creates empty bodies for methods inside ClassDefs.

It shouldn't be impossible to undo this assumption, but it may take some hacking to have a PR ready.

@scabug
Copy link
Author

@scabug scabug commented Jun 14, 2013

@scabug
Copy link
Author

@scabug scabug commented Jun 26, 2013

@adriaanm said:
merged for 2.10.x
master: scala/scala#2683 pending review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants