Do not skip extension methods. #144
Conversation
They are classified as “has a synthetic name” (i.e. contains a “$”) but regular use of these methods generates calls to the names from other compilation units. Fixes lightbend-labs#135.
|
Thanks for looking into this @szeiger! |
| @@ -0,0 +1 @@ | |||
| extension method c$extension(java.lang.String,Int)Unit in object A#B does not have a correspondent in new version | |||
There was a problem hiding this comment.
So is there a way of making such change in a compatible way..?
There was a problem hiding this comment.
No, I don't think so. Adding additional overloads should be fine but not adding a first overload.
The $extension methods get an appended number for disambiguation (see https://github.com/scala/scala/blob/9c5d3f81a667917b6a3aed5098182623c417c137/src/compiler/scala/tools/nsc/transform/ExtensionMethods.scala#L30-L38). It is not clear to me from that comment why we need to do this. The signature is the same as the one of the trait method, so I would expect that we can safely overload it in the same way.
Even if we cannot, perhaps we should use $extension0 instead of $extension for the non-overloaded case?
There was a problem hiding this comment.
Yes, a change in how extension methods are encoded such that overloads are binary compatible would be hugely beneficial.
They are classified as “has a synthetic name” (i.e. contains a “$”) but
regular use of these methods generates calls to the names from other
compilation units.
Fixes #135.