-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Distributed] Correct generic parameter handling in distributed func accessor (debug builds) #68859
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
[Distributed] Correct generic parameter handling in distributed func accessor (debug builds) #68859
Conversation
cb34c82
to
17e6ac3
Compare
3729dca
to
3af6777
Compare
Okey, this should be good to go now -- we don't actually want generics from the target on the accessor, but along the way we fixed how we handle the accessor signature somewhat. This has no wire impact, manglings remain the same -- just the accessor changed which isn't exposed externally. Testing all the confs is difficult for that so I expect a CI failure that I will follow up |
@swift-ci please test |
3af6777
to
e09411f
Compare
@swift-ci please smoke test |
We landed a bunch of other fixes with #68517 so now this PR seems is all good. |
@swift-ci please smoke test |
Pending on #70057 to unbreak CI |
@swift-ci please smoke test hmm why is this failing on CI; lost the job need to re-run |
6330df7
to
df2acf2
Compare
@swift-ci please smoke test |
df2acf2
to
e2d2ca0
Compare
The distributed func accessor does not need to carry forward generic parameters EXCEPT the Decoder and the self type. We adjust the implementation to pass those and correct handling of those parameters. This will now no longer produce crashes when distributed funcs are used in nested generic types in debug builds. This does not affect stable releases because those assertions are disabled there, and don't actually happen to cause issues here. But we should do the right thing in any case.
Resolves rdar://115497090
Resolves #68517
Old analysis:
If we don't do this, the generic parameter has no requirements at all, which a) is incorrect to begin with, it should have the exact same signature as the method it is the accessor for, and b) it would trip up verification which is enabled on linux in snapshot builds -- causing crashes.