-
Notifications
You must be signed in to change notification settings - Fork 10.5k
🍒[5.7][Distributed] Force the order of properties in AST #58747
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
🍒[5.7][Distributed] Force the order of properties in AST #58747
Conversation
@swift-ci please test |
@swift-ci please test |
CI having a bad day again
|
fix messed up rebase
0ada0f0
to
095f4e2
Compare
@swift-ci please test |
095f4e2
to
292bb7a
Compare
@swift-ci please test |
Sigh... this patch fixed it properly on main but seems something else needs to be cherry picked to 5.7 for the fix to work on watchsimulator-i386 - this is the only failure right now. Detective time... |
Checking if #42564 helps... |
@swift-ci please test macOS platform |
@swift-ci please test Linux |
See also rdar://92952551 for the watchos issue -- 5.7 seems to be missing some feature that makes this work on main... Will investigate separately |
b057898
to
f097d24
Compare
@swift-ci please test |
@swift-ci please test |
if (auto id = derived.Nominal->getDistributedActorIDProperty()) { | ||
derived.addMemberToConformanceContext(pbDecl, /*hint=*/id); | ||
derived.addMemberToConformanceContext(propDecl, /*hint=*/id); | ||
} else { |
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.
Would this else
ever be executed? Isn't getDistributedActorIDProperty
supposed to always return a valid id field either by returning pre-existing or synthesizing one?
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.
Hm yeah you’re right tbh.. I’ll update that
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.
Hm actually the nullptr might be returned when a cycle is detected in the request evaluator... Perhaps better safe and sorry here?
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.
Double checked -- you're right :) id does not request system so we're good
…t will always be synthesized or present already
Issue Summary:
Original PR: #58745
Radar:
Risk: Low, no impact on adopters
Details:
This is the actual solution for all our mystical offset issues -- the order of the synthesized AST fields MUST match the order IRGen enforces (and the DA needs in any case); where the id and system are the FIRST fields, and must be specifically: id, system because that's what IRGen emits and many places seem to expect the order matches between the original AST and whatever gets derived form it and IR.
This probably also resolves a few other crashers we had with similar crash reasons of weird mismatching offsets, I'll be verifying those.