-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[distributed] Require explicit assignment of actorSystem
#41740
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
55d67d2
to
fbdb527
Compare
What's left for this PR is:
|
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.
LGTM so far! This is looking really great; the impl ended up very clean thanks to the new attr as well.
1a82e75
to
af5d9cd
Compare
puttin out a feeler: @swift-ci please smoke test |
As we unlock the local init tests this also resolves rdar://86543336 |
we will no longer require exactly one ActorSystem-conforming parameter.
Konrad, myself, and others feel the longer name would be better, rather than just "system"
This attribute is designed for let-bound variables whose initializing assignment is synthesized by the compiler. This assignment is expected to happen at some point before DefiniteInitialization has run, which is the pass that verifies whether the compiler truly initialized the variable. I generally expect that this will never be a user-facing feature, and that the synthesized assignment happens in SILGen.
…of the actorSystem. The resignID call within the initializer moved into DI, because an assignment to the actorSystem, and thus initialization of the id, is no longer guaranteed to happen. Thus, while we previously could model the resignation as a clean-up emitted on all unwind paths in an initializer, now it's conditional, based on whether the id was initialized. This is exactly what DI is designed to do, so we inject the resignation call just before we call the identity's deinit.
Since the only user of `@_compilerInitialized` is distributed actors, I decided to make DI's diagnostics saying that such a var was not initialized a second-tier note. If there is some other var associated with the same Memory that is _not_ compiler initialized AND is also _not_ initialized, then we suppress the suggestion to initialize the @_compilerInitialized thing, because something else is problematic. Only when there are @_compilerInitialized things that are still not initialized, do we emit a note talking about that.
4f9a99e
to
456140b
Compare
@swift-ci please test |
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.
ok this edition looks good. just spotted some really minor clean-ups
Cool, let's clean those up separately and land this :) |
As discussed in https://forums.swift.org/t/specifying-the-controlling-actor-system-with-distributed-actors-se-0336-0344/55584
As of now, we require exactly one parameter of a designated initializer of a distributed actor to conform to DistributedActorSystem. Then we implicitly initialize self.actorSystem and self.id based using that parameter. The problem is that there is no explicit use of this parameter, so it seems / feels visually like it is not needed.
Instead, this PR changes things so that we require users to manually initialize the
actorSystem
property in the designated initializer's body, dropping the parameter requirement. Since we need to right-away initialize the ID after doing this, we would keep the implicit initialization of the ID.Resolves rdar://89582844 and rdar://86543336