-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
'implements' list order not deterministic #20496
Comments
Looking at the code it seems pretty plausible that this problem was caused by the set logic in 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! |
When a class contains calls to 'super' for traits it does not directly implement, these are added to the list of interfaces of the generated class. Previously, because these interfaces were determined using set logic, the ordering of that list was not deterministic. This makes the order deterministic assuming the order in which these calls are registered using `registerSuperCall` in the `CollectSuperCalls` phase is deterministic within each class. This seems likely to me but it'd be great if someone could confirm. To add a test for this change, creating a class that has many 'additional' traits and checking they are generated in the right order would make sense, but I couldn't find an obvious place for such a test. Any recommendations? Fixes scala#20496
When a class contains calls to 'super' for traits it does not directly implement, these are added to the list of interfaces of the generated class. Previously, because these interfaces were determined using set logic, the ordering of that list was not deterministic. This change makes the order deterministic (assuming the order in which these calls are registered using `registerSuperCall` in the `CollectSuperCalls` phase is deterministic within each class) Fixes scala#20496
When a class contains calls to 'super' for traits it does not directly implement, these are added to the list of interfaces of the generated class. Previously, because these interfaces were determined using set logic, the ordering of that list was not deterministic. This change makes the order deterministic (assuming the order in which these calls are registered using `registerSuperCall` in the `CollectSuperCalls` phase is deterministic within each class) Fixes #20496 [Cherry-picked 7500b05][modified]
When a class contains calls to 'super' for traits it does not directly implement, these are added to the list of interfaces of the generated class. Previously, because these interfaces were determined using set logic, the ordering of that list was not deterministic. This change makes the order deterministic (assuming the order in which these calls are registered using `registerSuperCall` in the `CollectSuperCalls` phase is deterministic within each class) Fixes #20496 [Cherry-picked 7500b05][modified]
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 withTimers, Actor
in one build but withActor, Timers
on another.The definition of this class is:
where:
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 haveActor
andTimer
on theimplements
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.
The text was updated successfully, but these errors were encountered: