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-11268] Builtins for objc_msgSend/objc_msgSend_super #53669

Open
Catfish-Man opened this issue Aug 8, 2019 · 3 comments
Open

[SR-11268] Builtins for objc_msgSend/objc_msgSend_super #53669

Catfish-Man opened this issue Aug 8, 2019 · 3 comments
Labels
compiler The Swift compiler in itself improvement

Comments

@Catfish-Man
Copy link
Member

Previous ID SR-11268
Radar None
Original Reporter @Catfish-Man
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement
Assignee None
Priority Medium

md5: cb83d905c400d8322d6435593b784d15

relates to:

  • SR-11249 Using @_effects(releasenone) is tricky with shadow protocols

Issue Description:

Note: this would obviate the need for https://bugs.swift.org/browse/SR-11249 entirely

The stdlib has a trick that it uses to interact with Cocoa that we've dubbed "shadow protocols". The basic idea is this:

@objc protocol Shadow {
    @objc(doThing:) func doTheThing() -> Int
}
 
@_effects(releasenone)
private func doThingImpl(_ x: Shadow) -> Int {
    return x.doTheThing()
}
 
@_effects(releasenone)
func cocoaDoThing(_ x: AnyObject /* but we know it's actually a particular ObjC object type */) -> Int {
    return doThingImpl(_unsafeReferenceCast(x, to: Shadow.self))
} 

This is quite a bit of fiddly machinery for what's ultimately a simple task: call objc_msgSend with a particular selector and calling convention. It gets even more hairy when we want to call objc_msgSend_super instead.

Could we have a direct way to express this?

@belkadan
Copy link
Contributor

I don't see how the builtin would help much. It still wouldn't be releasenone.

@Catfish-Man
Copy link
Member Author

My claim here, which may be incorrect, is that the step that's losing the release none is the bitcast. If we had a way like this to just say "no really just send a message to this object, I know you don't think it will work" then there'd be no reason to bitcast.

@Catfish-Man
Copy link
Member Author

(Casting some doubt on this I was unable to reproduce the extra refcounting in a standalone test case >.<)

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

No branches or pull requests

2 participants