Skip to content
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

[SR-11233] Many Foundation crashes due to invalid casts #3395

Open
ephemer opened this issue Jul 30, 2019 · 2 comments
Open

[SR-11233] Many Foundation crashes due to invalid casts #3395

ephemer opened this issue Jul 30, 2019 · 2 comments

Comments

@ephemer
Copy link

ephemer commented Jul 30, 2019

Previous ID SR-11233
Radar None
Original Reporter @ephemer
Type Bug
Environment

Android: armv7a, arm64-v8a, x86_64 confirmed
Linux: Probably?
Darwin: Probably not- assuming this only happens in the non-objc paths

Additional Detail from JIRA
Votes 0
Component/s Foundation
Labels Bug
Assignee None
Priority Medium

md5: 6d906e4ba53d6d7fe5fe5925a0bd30ae

Issue Description:

Many Foundation APIs take Any as an input, two examples of which are:

  • Notification (public init(name: Name, object: Any? = nil, userInfo: [AnyHashable : Any]? = nil))

  • NSAttributedString(one of many examples being open func addAttribute(_ name: NSAttributedString.Key, value: Any, range: NSRange) )

Using these APIs on Android (and presumably on other non-objc-supporting platforms) results in a crash on the current master when providing values to the Any parameters that are not NSObject s. This seems to be due to Foundation/Bridging.swift:199 which performs a force-cast: return (value as AnyObject) as! NSObject

This seems to be an unintended bug to me (if these APIs should only accept AnyObject / NSObject, let's say so in the API contract, but my gut feeling is that that shouldn't be necessary). It's possible that value as AnyObject casting has been broken by recent changes in Swift itself. It would be good to get some insight as to what's changed here and what we can do to fix it.

@ephemer
Copy link
Author

ephemer commented Jul 30, 2019

@millenomi I'm tagging you because you made the last functional changes in Bridging.swift (even though I don't think those changes are causing the current issue)

ianpartridge (JIRA User) I'm tagging you because I understand you may have an idea of when this issue started happening and/or whether it's expected behaviour

@compnerd I'm tagging you because you're also working on Android and because of apple/swift@3ec6e12#diff-2ffdcc47511e4607c7d36446a7ab4480 which I don't really understand but touches vaguely related code.

@millenomi
Copy link
Contributor

It makes sense as a bug to fix — on Darwin, all Swift objects can respond to NSObject methods when passed to an ObjC method, but not all of them do or are in s-c-f. You can work around this for now by making objects NSObjects, but we should honor the contract and allow any value, or box those objects in __SwiftValues (which are NSObjects).

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants