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

Generate Objective-C interfaces for Swift declarations #136

Open
beltex opened this issue Jan 2, 2015 · 11 comments
Open

Generate Objective-C interfaces for Swift declarations #136

beltex opened this issue Jan 2, 2015 · 11 comments

Comments

@beltex
Copy link
Contributor

beltex commented Jan 2, 2015

I'm certain this is already known, but thought it be handy to have as a placeholder for reference nonetheless. Feel free to close if not, and of course #56 is a pre-req for this.

Independent of the source of the API (C/Obj-C, Swift), generate the interface (declarations) for both Objectivce-C & Swift (as an option) as seen in Apple's docs already (with the Language option). Of course, not everything translates both ways (complex macros --> Swift, tuples --> Obj-C).

As a side note, for those interested in this from the Swift side, the @objc annotation in Swift would help. Tells the compiler to check if the method in question is compatible with Objective-C. See Using Swift with Cocoa and Objective-C book from Apple for more.

@jpsim
Copy link
Collaborator

jpsim commented Jan 2, 2015

Thanks for filing this issue.

We could do this for Swift source right now, but we'd first have to identify how Xcode generates the -Swift.h file.

#56 will of course be a pre-requisite to generating the Swift version of Objective-C declarations.

@Bierrot
Copy link

Bierrot commented Mar 5, 2015

Same here. It would be very nice to have both declarations (obj-c and swift) in jazzy doc.

@jpsim
Copy link
Collaborator

jpsim commented Nov 24, 2015

There's a proof of concept PR towards SourceKitten that builds towards this: jpsim/SourceKitten#95

@fabb
Copy link

fabb commented May 12, 2016

Don't mean to hijack the thread, but maybe you can help: I want to generate the Swift Interface for our ObjC Bridging Header via commandline, is that somehow possible (without generating the full-fledged documentation from jazzy)?

@jpsim
Copy link
Collaborator

jpsim commented Jun 9, 2016

As of #530, Objective-C declarations also include their Swift equivalent when appropriate.

I haven't found a good way to do it the other way around though, so I'd appreciate any help from contributors here 😄

@jpsim jpsim changed the title Generate Objective-C & Swift interfaces independent of API source Generate Objective-C interfaces for Swift declarations Jun 14, 2016
@karagraysen karagraysen self-assigned this Nov 23, 2016
@karagraysen
Copy link
Contributor

Seems that this issue has been resolved so I'm going to close the issue. Lmk if I'm wrong or if we need to reopen the issue.

@1ec5
Copy link
Collaborator

1ec5 commented Nov 23, 2016

Are you sure? Last I checked, jazzy generated Swift signatures for Objective-C symbols, but not the other way around.

@karagraysen
Copy link
Contributor

I'll look into it. Re-opening for now.

@karagraysen karagraysen reopened this Nov 23, 2016
@jpsim
Copy link
Collaborator

jpsim commented Nov 26, 2016

I still haven't figured out how to perform the swift->objc translation.

@akhilcb
Copy link

akhilcb commented Mar 7, 2018

Just wondering if there is any progress on this since it has been two years.

@johnfairh
Copy link
Collaborator

If you (or anyone!) would like to work on this, the best way I've come up with to do this is:

As PoC, drive from jazzy layer:

  1. Generate the Swift sourcekitten json structures as normal.
  2. Generate bridging header for the Swift module.
    (This contains ObjC defns for Swift decls marked @objc.)
    Use swiftc -emit-objc-header-path and build module, or dig out of initial sourcekitten build, experimentation needed for most efficient ways ....
  3. Run sourcekitten doc --objc on the bridging header.
  4. Traverse the bridging header json and spot ObjC declarations that match Swift ones.
    This is easy because the USR fields match.
    (Haven't proved this is always true, seems to hold for simple examples though - will need testing and maybe study of Swift's PrintAsObjC code.)
  5. Tweak jazzy's Ruby code to understand that there can be two declarations in Swift mode. Should be light relief after the previous parts.

Fully integrated version would do 1-3 in sourcekitten and could optimise the 2/3 steps by just pointing libclang at the header and iterating over it for USRs without generating the intermediate json.

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

8 participants