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
In Objective-C it's not uncommon to check in runtime whether a particular class re-implements a method or property for "conformance" tests. It is important to make sure that Swift retains this behavior and does not elide declarations attributed with `@objc`.
In Apple's Foundation there the `NSSecureCoding` protocol. Every class and every subclass must implement the `supportsSecureCoding` class property to confirm and re-confirm conformance.
Currently, when compiled with optimizations for Release, the override is elided and an attempt to archive via `try! NSKeyedArchiver.archivedData(withRootObject: B(), requiringSecureCoding: true)` fails with an error because the runtime check saw implementation in `A` but haven't seen one in `B`.
The text was updated successfully, but these errors were encountered:
Environment
Apple Swift version 5.1.3
Additional Detail from JIRA
md5: 71d3ea58c1bb2848d7e06568181d41f6
Issue Description:
In Objective-C it's not uncommon to check in runtime whether a particular class re-implements a method or property for "conformance" tests. It is important to make sure that Swift retains this behavior and does not elide declarations attributed with `@objc`.
In Apple's Foundation there the `NSSecureCoding` protocol. Every class and every subclass must implement the `supportsSecureCoding` class property to confirm and re-confirm conformance.
Currently, when compiled with optimizations for Release, the override is elided and an attempt to archive via `try! NSKeyedArchiver.archivedData(withRootObject: B(), requiringSecureCoding: true)` fails with an error because the runtime check saw implementation in `A` but haven't seen one in `B`.
The text was updated successfully, but these errors were encountered: