Dotty cannot read Scalac @specialized annotations

[DarkDimius]

https://github.com/lampepfl/dotty/blob/master/src/dotty/tools/dotc/core/pickling/UnPickler.scala#L829
Dotty always assumes that default constructor of annotation is called. That's not true for common case of @specialized(Int).

[odersky]

Ouch. It looks like the Unpickler has to invoke resolveOverloaded to get to the right constructor. That's not nice at all, but I do not see a better alternative.

[DarkDimius]

I was able to reuse resolveOverloaded to get overloading resolution and ApplyToTyped to get argument adaptation(eg varagrs handling).
But now I see failures due to resolveOverloaded executing
narrowByTrees(alts2, pt.typedArgs, resultType)
ie: trying to retype argument trees. Which fails due to those trees not having a position set.

This rises a question of should positions be set for annotation trees read from bytecode or not. As those trees aren't representing a code that is in control of user I would say that any synthetic position should be ok.

@odersky, Do you have a better idea?

[odersky]

Good that resolveOverloaded works. I don't see right now how narrowByTrees
would fail because of missing positions. Let's see a stacktrace tomorrow.

On Wed, Oct 29, 2014 at 9:47 PM, Dmitry Petrashko notifications@github.com
wrote:

I was able to reuse resolveOverloaded to get overloading resolution and
ApplyToTyped to get argument adaptation(eg varagrs handling).
But now I see failures due to resolveOverloaded executing
narrowByTrees(alts2, pt.typedArgs, resultType)
https://github.com/lampepfl/dotty/blob/master/src/dotty/tools/dotc/typer/Applications.scala#L953
ie: trying to retype argument trees. Which fails due to those trees not
having a position set.

This rises a question of should positions be set for annotation trees read
from bytecode or not. As those trees aren't representing a code that is in
control of user I would say that any synthetic position should be ok.

@odersky https://github.com/odersky, Do you have a better idea?

—
Reply to this email directly or view it on GitHub
#205 (comment).

Martin Odersky
EPFL

[DarkDimius]

should be fixed in #206