-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Distributed] Only synthesize Codable for DA where the ID is Codable #72081
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
Conversation
I wonder if @ser-0xff @hassila have hit this issue in https://github.com/ordo-one/package-distributed-system since it seems you use your own serialization requirement but had to make the actor and id codable anyway. This should remove forcing people into this un-necessary conformance. |
@swift-ci please smoke test |
if (!systemTy->getAnyNominal()) | ||
return false; | ||
|
||
auto idTy = getDistributedActorSystemActorIDType(systemTy->getAnyNominal()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actor system doesn't have to be a concrete nominal type for ActorID
to be available (i.e. I think it could be stated as a same-type requirement?), maybe better use getAssociatedTypeOfDistributedSystemOfActor
or directly substitute ActorSystem.ActorID
dependent member?...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, I'll add a test like that and cover it. Same type requirement should be the case you're mentioning yeah
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh weirdly enough facing term verification crashes that I don't quite understand when trying to use the getAssociatedTypeOfDistributedSystemOfActor
here... I dug around for a while but will need to ask @slavapestov for a hint I think
e66378d
to
15cfbe2
Compare
In the our implementation the ID type was codable from the very beginning because we transmitted it between server and client, but recently we made some changes so do not transmit the whole ID any more. Probably will make sense to remove that conformance. |
@swift-ci please smoke test |
I see, thanks @ser-0xff -- I thought you had run into this issue and were forced to do Codable there. |
@swift-ci please smoke test Linux |
1 similar comment
@swift-ci please smoke test Linux |
@swift-ci please smoke test Windows |
15cfbe2
to
738a018
Compare
This doesn't handle the
yet but I'm working on it. Seems the new code in auto *actorType = actorOrExtension->getSelfNominalTypeDecl();
if (isa<ProtocolDecl>(actorType))
return memberTy->getReducedType(sig); still isn't quite good enough:
|
@swift-ci please smoke test |
Turns out we actually don't want to support the inference of Codable for a protocol anyway -- and it would have been cyclic. So we're good as soon as CI is happy from unrelated issues |
@swift-ci please smoke test macOS |
This is a bug in synthesis we only noticed recently. The design is such that a distributed actor shall be Codable when the ID is Codable. But we wrongly always added the conformance and thus synthesis would fail when IDs were not Codable.
This forced adopters to make their ID types Codable even though they were not using Codable at all.
The implementations come from:
We are not extending this implicit conformance to other types, so this is just a fix of behavior.
resolves rdar://122930345