-
Notifications
You must be signed in to change notification settings - Fork 148
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
chore: Update scala to 3.3.4 #1474
Conversation
https://github.com/apache/pekko/actions/runs/10808811742/job/29982581675?pr=1474#step:8:646 @WojciechMazur it reports mima issue now |
These are |
See apache/pekko-connectors#749 - has similar mima issues and some comments from the Dotty team. |
Here's the reproducer: import scala.annotation.unchecked.uncheckedVariance
object scaladsl{
trait FlowOpsMat[+Out, +Mat] {
type Repr[+O] <: ReprMat[O, Mat] {
type Repr[+OO] = FlowOpsMat.this.Repr[OO]
type ReprMat[+OO, +MM] = FlowOpsMat.this.ReprMat[OO, MM]
}
type ReprMat[+O, +M] <: FlowOpsMat[O, M] {
type Repr[+OO] = FlowOpsMat.this.ReprMat[OO, M @uncheckedVariance]
type ReprMat[+OO, +MM] = FlowOpsMat.this.ReprMat[OO, MM]
}
}
trait FlowOps[+Out, +Mat] {
type Repr[+O] <: FlowOps[O, Mat] {
type Repr[+OO] = FlowOps.this.Repr[OO]
}
}
trait SubFlow[+Out, +Mat, +F[+_], C] extends FlowOps[Out, Mat] {
override type Repr[+T] = SubFlow[T, Mat @uncheckedVariance, F @uncheckedVariance, C @uncheckedVariance]
}
final class [-In, +Out, +Mat] extends FlowOpsMat[Out, Mat]{
override type Repr[+O] = Flow[In @uncheckedVariance, O, Mat @uncheckedVariance]
override type ReprMat[+O, +M] = Flow[In @uncheckedVariance, O, M]
}
final class Sink[-In, +Mat]
}
class SubFlow[In, Out, Mat](
delegate: scaladsl.SubFlow[Out, Mat, scaladsl.Flow[In, Out, Mat]#Repr, scaladsl.Sink[In, Mat]]) {
def asScala: scaladsl.SubFlow[Out, Mat, scaladsl.Flow[In, Out, Mat]#Repr, scaladsl.Sink[In, Mat]] @uncheckedVariance =
delegate
} Compilation with both Scala 2.13 and 3.3.4-RC2 would produce the following signatures: private final scaladsl$SubFlow<Out, Mat, ?, scaladsl$Sink<In, Mat>> delegate;
descriptor: Lscaladsl$SubFlow;
Signature: #19 // Lscaladsl$SubFlow<TOut;TMat;*Lscaladsl$Sink<TIn;TMat;>;>;
public scaladsl$SubFlow<Out, Mat, ?, scaladsl$Sink<In, Mat>> asScala();
descriptor: ()Lscaladsl$SubFlow;
Signature: #22 // ()Lscaladsl$SubFlow<TOut;TMat;*Lscaladsl$Sink<TIn;TMat;>;>; In Scala 3.3.3 we were generating private final scaladsl$SubFlow<Out, Mat, scaladsl$Flow<In, java.lang.Object, Mat>, scaladsl$Sink<In, Mat>> delegate;
descriptor: Lscaladsl$SubFlow;
Signature: #19 // Lscaladsl$SubFlow<TOut;TMat;Lscaladsl$Flow<TIn;Ljava/lang/Object;TMat;>;Lscaladsl$Sink<TIn;TMat;>;>;
public SubFlow(scaladsl$SubFlow<Out, Mat, scaladsl$Flow<In, java.lang.Object, Mat>, scaladsl$Sink<In, Mat>>);
descriptor: (Lscaladsl$SubFlow;)V
Signature: #22 // (Lscaladsl$SubFlow<TOut;TMat;Lscaladsl$Flow<TIn;Ljava/lang/Object;TMat;>;Lscaladsl$Sink<TIn;TMat;>;>;)V tl;dr @lrytz / @sjrd I believe it was introduced in scala/scala3#20463 and was targeting a fix to generic signatures of value classes. Do you think it's something that can be considered a regression? From the fact that |
Not immediately obvious to me. Maybe someone can narrow it down to a minimal self-contained reproducer? |
Here's further minimization using both contravariant and covaraint param types import scala.annotation.unchecked.uncheckedVariance
trait SubFlowDef[+F[+_]]
final class Flow1[-In]{
type Repr[+O] = Flow1[In @uncheckedVariance]
}
final class Flow2[+Out]{
type Repr[+O] = Flow2[O]
}
class SubFlow[In, Out](
delegate1: SubFlowDef[Flow1[In]#Repr],
delegate2: SubFlowDef[Flow2[Out]#Repr]
)
Signatures: public SubFlow(SubFlowDef<?>, SubFlowDef<Flow2>);
descriptor: (LSubFlowDef;LSubFlowDef;)V
Signature: #9 // (LSubFlowDef<*>;LSubFlowDef<LFlow2;>;)V Scala 2.13 public SubFlow(SubFlowDef<?>, SubFlowDef<?>);
descriptor: (LSubFlowDef;LSubFlowDef;)V
Signature: #12 // (LSubFlowDef<*>;LSubFlowDef<*>;)V Scala 3.3.3 public SubFlow(SubFlowDef<Flow1<In>>, SubFlowDef<Flow2<java.lang.Object>>);
descriptor: (LSubFlowDef;LSubFlowDef;)V
Signature: #9 // (LSubFlowDef<LFlow1<TIn;>;>;LSubFlowDef<LFlow2<Ljava/lang/Object;>;>;)V It seems that in Scala 2.13 all generic param types (both covariant and invariant) are transformed to wildcard types. In 3.3.4-RC2 / 3.5.0 contravariant type is preserved and in 3.3.3- both contravariant and covariant types were preserved. |
I did a quick test with the current scala3/main branch, the signature change doesn't seem to be caused by this PR. I reverted the PR and the signature stays the same. |
I've bisected the compiler and found out it was due to change in the typer - scala/scala3#21576 (comment). I also suggest to move further discussions to dedicated compiler issue. |
👍 sorry I missed the scala3 ticket |
The change introducing change to generic signatures of HKT was reverted in 3.3.4-RC4. I've tested locally that it no longer triggers invalid generic signature errors in Pekko. It's because covariant Higher Kinded Types were producing invalid signatures (not following spec). |
There's some weird thing going in the From what I've observed locally test fails if I would be grateful for any pointers as to why it might happened, so we can prepare a reproducer. |
The outputs of
in 3.3.4
I belive it was introduced in scala/scala3#19803 but need to confirm it yet. Mentioned PR optimized generated code in such a way that it allowed some unused value to be skipped. |
Actually, the change was introduced in scala/scala3#19251 It affects all Scala versions since 3.4.0 and now was backported to 3.3.4. |
@WojciechMazur thanks for your research on this latest issue with those log capturing test scenarios. It would be nice if Scala 3.3.4 was able to handle the existing way these tests run but if not, the Pekko team will have to decide on whether
|
I would opt for the second solution. If the user of pekko is compiling its project using 3.4.0 or later, then the new behavior is already applied to them. End users (applications) are encouraged to use the latest Scala version (Scala Next series) so they might already be dealing with it. |
I think previous behaviour can be restored with a small amount of overhead. What's important here is the fact that we should search for What's more by having a little more of additional overhead at the time of behaviour definition, you'd be able to have a consistent behaviour for Scala 3.4.0+ users right now |
see #1506 |
test with 3.3.4-RC4