@varargs method and separate compilation

[iulian dragos]

Hi all,

I just filed SI-10071 and I’m willing to take a shot at fixing it, but I want to check first if:

• there’s interest in a fix
• the approach I have in mind is sound

Here’s what happens:

Methods annotated with @varargs get a forwarder that can be called from Java as a vararg method. This transformation is done in uncurry in the tree transformer, so in my example:

import scala.annotation.varargs

trait AbstractProps {
  @varargs def create(x: Int, y: Int*): AbstractProps = null
  // added by uncurry
  <synthetic> def create(x: Int, y: Array[Int]): AbstractProps = create(x, Predef.wrapIntArray(y));
}

Now, if this trait is mixed in another class, this method won’t be added unless the two classes are compiled together. The reason is that uncurry is after pickler so the java vararg method is not in the type of AbstractProps when all we have for AbstractProps is a symbol.

The usual way to deal with such problems is to split the transformation in two parts:

• an info transform that adds the synthetic method symbol to the owner. This happens for all symbols, whether they come from source or binaries
• a tree transformation that provides an implementation for that symbol. This only happens then we actually compile that class

Uncurry is already an info transformer, so the phase has the two parts already. However, java varargs did not follow this pattern.

Is there a better way than to move this method symbol creation to the info transformer (who, by the way, lives in scala.reflect.internal)?

iulian

​

--

« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Lukas Rytz]

That sounds like the right approach to me.

Thanks!

Lukas

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[iulian dragos]

On Fri, Nov 18, 2016 at 4:35 PM, Lukas Rytz <lukas...@gmail.com> wrote:

That sounds like the right approach to me.

Excellent! Any recommendation on linking the new symbol to the original method? In the tree transformer I need to find the "right" forwarder symbol so I reuse it in the tree. 

thanks,

iulian

[Lukas Rytz]

On Fri, Nov 18, 2016 at 4:47 PM, iulian dragos <jagu...@gmail.com> wrote:

On Fri, Nov 18, 2016 at 4:35 PM, Lukas Rytz <lukas...@gmail.com> wrote:

That sounds like the right approach to me.

Excellent! Any recommendation on linking the new symbol to the original method? In the tree transformer I need to find the "right" forwarder symbol so I reuse it in the tree. 

We're using attachments more and more lately for this kind of things.

Maybe an exitingUncurry will be necessary?

I don't have time right now to find examples, sorry..