clone wars

[Jason Zaugg]

Consider:

trait U { type A }

object Test {

  def foo(u: U)(as: List[Any]): u.A = ???

}

qbin/scalac  -uniqid -Xprint:uncurry sandbox/test.scala | grep foo

def foo#7305(

  u#12154: U#6993, 

  as#12155: List#11181[Any#3329]

): u#16626.A#7301 = ...

Uncurry's info transformer sometimes [1] uses clones for the parameter symbols. Those clones are visible in `fooDefDef.symbol.info`. But the parameter ValDefs, and types in the RHS of the DefDef still refer to the original parameter symbols.

This is enough to trigger a crash in tail call elimination, see SI-6900.

One can turn a blind eye to the problem but emitting casts [2], but this seems to be a huge bug magnet, so I'd like to hear ideas for less hacky fix.

It also prompted me to question my change for SI-6443, in which I changed the tree transformer in Uncurry but left the info transformer unchanged. (Instead, I updated the symbol info in the tree transformer [3]).

Thoughts, comments, suggestions?

-jason

[1] if it can get away without cloning, it does, see `TypeMap#noChangeToSymbols`. In the code above, use of the type alias `scala.List` is enough to use clones.

[2] https://github.com/retronym/scala/compare/ticket/6900

[3] https://github.com/scala/scala/pull/1857/files#L0R876

[Paul Phillips]

On Fri, Feb 22, 2013 at 8:05 AM, Jason Zaugg <jza...@gmail.com> wrote:

Thoughts, comments, suggestions?

When a symbol is cloned with a new owner, every info in its type history should also be cloned onto the clone. Don't all these inconsistencies melt away? 

This is kind of what I'm working on right now. I have finally, finally, finally beaten the whole SI-3452 business. Many interlocking issues, one of which is definitely errors introduced by cloning. (Hey, just like real cloning.)

[Jason Zaugg]

On Fri, Feb 22, 2013 at 5:40 PM, Paul Phillips <pa...@improving.org> wrote:

On Fri, Feb 22, 2013 at 8:05 AM, Jason Zaugg <jza...@gmail.com> wrote:

Thoughts, comments, suggestions?

When a symbol is cloned with a new owner, every info in its type history should also be cloned onto the clone. Don't all these inconsistencies melt away? 

Does that directly help this case? The divergence here is that an InfoTransformer conjures the new symbols for a MethodType, but the corresponding DefDef tree still contains the old symbols in Def- and RefTrees.

 

This is kind of what I'm working on right now. I have finally, finally, finally beaten the whole SI-3452 business. Many interlocking issues, one of which is definitely errors introduced by cloning. (Hey, just like real cloning.)

Consider my breath bated.

-jason 

[Paul Phillips]

On Fri, Feb 22, 2013 at 8:48 AM, Jason Zaugg <jza...@gmail.com> wrote:

Does that directly help this case? The divergence here is that an InfoTransformer conjures the new symbols for a MethodType, but the corresponding DefDef tree still contains the old symbols in Def- and RefTrees.

Sorry, I misunderstood the issue. We are back to the usual grand problem of keeping trees, symbols, and types in tune with one another. One can't help but sense there is a better way out there.

Is there some occasion when we would want a DefDef to carry a method symbol the parameters of which are different than the symbols found on vparamss? It seems like we could rule some of this out by construction.

[Jason Zaugg]

Allowing it seems to be a path only to pain. I wonder what we would change to keep them synchronized. TypeMaps clone in general, but can we customise the TypeMap that backs an InfoTransformer to disable cloning? For all symbols or just for some?

-jason