Introduce staged lowering of Swift to @_cdecl Swift to C
#214
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We're going to separate out the lowering of Swift declarations to C from the handling of those C declarations on the Java side. That's cleaner and more generalizable.
Swift functions are lowered into C-compatible thunks. Those thunks currently have their types represented in Swift, which is needed for the `@_cdecl` declaration. Introduce a representation of the C type system so that we can describe the specific C types that each parameter has. This intentionally represents C types in an abstract form that fits will with the mapping from Swift, for example representing integral types by the number of bits and their signedness, rather than the actual C primitive types like `int` or `unsigned long`. Implement printing of C types and functions, in case we decide that we want to render C declarations for consumption by humans or tools that want to bind to them.
Leverage the new C type system so that we can lower Swift cdecl functions down to their C representation. This could be used to generate C headers (albeit ugly ones) in the future, but for now is part of the validation of lowering Swift functions to cdecl thunks.
This matches what we're doing elsewhere, and also the way that the Swift calling convention is lowered to LLVM IR by the compiler.
Make the operation to convert from cdecl parameter(s) into a Swift parameter a standalone operation, separate from the lowering of Swift parameters to cdecl parameters. They need to be synchronized, but they are not the same.
Implement a separate "swift to cdecl" conversion path that turns a Swift value into cdecl-compatible return values. This includes returning class and actor references (as unsafe raw pointers), unsafe pointers (also as unsafe raw pointers), and returned tuples (which are passed indirectly).
This is meant to match the existing thunk generation.
This requires us to walk the parallel structure between indirect returns (where we need to introduce the initialize(to:) calls instead of pointee references) and the Swift value.
When lowering a Swift function to a cdecl thunk, detect when a given Swift type is exactly representable in C. In such cases, just keep the type as written and pass it through without modification. Use this to allow `@convention(c)` functions to go through untouched.
Consistency be damned, it's what looks nice. Clang does it too.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduce a different approach to creating
@_cdeclthunks that looks a lot more like what the compiler does, breaking down Swift abstractions (things like tuples) to create new function signatures and patterns to follow to convert between the Swift-native values and the@_cdecl-compatible ones.This approach also comes with a model of the C type system so we can take a
@_cdeclfunction and produce the corresponding C declaration (e.g, similar to a generated header). At present, this is used mostly for testing that the C lowering looks like it should, but it's also potentially a handy reference when (e.g.) figuring out how to encode the function signature in Java's Foreign Function & Memory Interface.This is not quite ready to wire into the main parts of jextract-swift yet. It still needs to handle optionals and function conversions.