search

Snapchat / djinni

A tool for generating cross-language type declarations and interface bindings. Djinni's new home is in the Snapchat org.
Apache License 2.0
180 stars 50 forks source link

Swift 6 Concurrency Macro Support #173

Open bthomale opened 5 months ago

bthomale commented 5 months ago

We've started adding support for Swift 6 concurrency checking to an app that uses djinni. Most of my djinni obj-c++ interfaces need to be marked with things like @MainActor (using the macro NS_SWIFT_UI_ACTOR) but I don't want to hand-modify the generated obj-c interface files, because of course they'd be overwritten the next time someone rebuilds the djinni files.

These are documented here: https://www.swift.org/migration/documentation/swift-6-concurrency-migration-guide/incrementaladoption#CObjective-C

It would be really nice if there were some syntax that would let us mark these in our djinni interfaces. I think it'd be fine if it only affected objective-C interface generation, and C++ / Java / JNI just ignored it.

We'd at the least need NS_SWIFT_UI_ACTOR, NS_SWIFT_NONISOLATED, and NS_SWIFT_SENDABLE I think? Those seem like the most important.

What I'm probably going to do for now is come up with some way to represent this in a comment, and then run some sort of post-processing script that looks for comments and replaces them with the appropriate macros.

For example, I'm thinking something simple like: # @MainActor

And then I'd just run a script after every djinni build that searches for those comments in the obj-c headers, replacing them with the appropriate macros. The downside is that the other platforms would end up with some odd comments in their headers, but at least it would solve the problem.

It would be nice if djinni had a supported way of doing this. (Is there a cleaner way to extend djinni to add stuff like this already? Does anyone know?)

bthomale commented 5 months ago

I created my script, and it seems to work fine. I modified the makefile we use to trigger djinni to run the script after it updates the djinni files. It looks for the following markers before a record / class declaration (at the end of a comment block):

# @MainActor # @Sendable

And inserts NS_SWIFT_UI_ACTOR and NS_SWIFT_SENDABLE immediately after the comment block.

It also looks for nonisolated on a line by itself before a function definition: # @nonisolated

When it encounters this, it inserts NS_SWIFT_NONISOLATED before the semicolon, on the next line ending in a semicolon. (So, the end of the function.)

Pretty simple and meets my needs for now. If there were some way to extend djinni to do this for us, that'd be great? (I can't imagine I am the only one that needs this.) Just documenting the syntax I used here in case it is helpful.