'implements' list order not deterministic
Closed this issue · 1 comments
Compiler version
3.3.3
Minimized code
(not minimized yet)
On version 1.1.0-M1 of Pekko, the order of the imports on org.apache.pekko/cluster.sharding.PersistentShardCoordinator
was not deterministic: it ended with Timers, Actor
in one build but with Actor, Timers
on another.
The definition of this class is:
class PersistentShardCoordinator(
override val typeName: String,
settings: ClusterShardingSettings,
allocationStrategy: ShardCoordinator.ShardAllocationStrategy)
extends ShardCoordinator(settings, allocationStrategy)
with PersistentActor
where:
class ShardCoordinator extends Actor with Timers
trait PersistentActor extends Eventsourced with PersistenceIdentity
trait Eventsourced extends Snapshotter with PersistenceStash with PersistenceIdentity with PersistenceRecovery
trait Snapshotter extends Actor
trait PersistenceRecovery
trait PersistenceIdentity
trait PersistenceStash extends Stash with StashFactory
trait Stash extends UnrestrictedStash with RequiresMessageQueue[DequeBasedMessageQueueSemantics]
trait UnrestrictedStash extends Actor with StashSupport
trait StashSupport
trait RequiresMessageQueue[T]
trait StashFactory { this: Actor =>
}
I tried to put together a reproducer at https://codeberg.org/raboof/scala3-reproduce-20496/src/branch/main/Test.scala but there ShardCoordinator.class
doesn't have Actor
and Timer
on the implements
list directly at all - I'm not sure how exactly that's triggered, happy to take suggestions :)
Expectation
Compiling the same source on a clean system should produce the same bit-by-bit result each time.
Looking at the code it seems pretty plausible that this problem was caused by the set logic in Symbol.superInterfaces
(in BTypesFromSymbols.scala
).
Updated https://codeberg.org/raboof/scala3-reproduce-20496 so it now recreates that scenario, though being a nondeterminism it's still hard to trigger.
Created a tentative fix in #20593, though this is unfamiliar territory for me so I'd appreciate any feedback!