You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Restore Prior Behavior for NSCopying Lookup in Subscript Type Mapping
Bear with me, this is going to get weird.
Swift has to import -[NSDictionary objectForKeyedSubscript:] with a special NSCopying
bound that otherwise does not appear in source. This involves the clang importer
looking very specifically for this selector, on this type, in Foundation. The old
behavior was to try to run a type lookup for NSCopying then bail if that failed.
With the introduction of explicit existentials, the failure path changed to check
if the existential itself is NULL. That's currently an impossible condition. What instead
happens is that if your SDK is broken we submit a NULL NSCopying primitive to the
ExistentialType constructor and crash in +asserts compilers.
Quite how you wind up in this position in real
world setups is a mystery - if the Foundation module were somehow corrupt, or the module
cache returned an incoherent type entry lacking a definition for NSCopying we could crash
here. In fact, you can replicate this crash by removing the definition for NSCopying in the
mock SDK and leaving behind a forward declaration!
Since this condition is not representative of an expected setup, restoring the old behavior
sans test is probably the right way to go.
rdar://91062370
0 commit comments