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

Initial implementation of a new lowering from a Swift func to @_cdecl func #210

Merged
merged 1 commit into from
Jan 23, 2025

Conversation

DougGregor
Copy link
Member

Start implementing a more complete and formal lowering from an arbitrary Swift function to a @_cdecl-compatible thunk that calls that function. This is set up in stages more akin to what you'd see in a compiler:

  1. Resolve the syntax trees for the function into a more semantic representation, for example resolving type names to nominal type declarations. This includes a simplistic implementation of a symbol table so we can resolve arbitrary type names.
  2. Lower the semantic representation of each function parameter (including self). How we do this varies based on type:
  • Value types (struct / enum) are passed indirectly via Unsafe(Mutable)RawPointer, using a mutable pointer when the corresponding parameter is inout.
  • Class / actor types are passed directly via UnsafeRawPointer.
  • Swift types that map to primitive types (like Swift.Int32) in passed directly, no translation required.
  • Tuple types are recursively "exploded" into multiple parameters.
  • Unsafe*BufferPointer types are "exploded" into a pointer and count.
  • Typed unsafe pointers types are passed via their raw versions.
  1. Lower returns similarly to parameters, using indirect mutable parameters for the return when we can't return directly.
  2. Render the lowered declaration into a FunctionDeclSyntax node, which can be modified by the client.

At present, we aren't rendering the bodies of these thunks, which need to effectively undo the transformations described in (3) and (4). For example, reconstituting a tuple from disparate arguments, appropriately re-typing and loading from indirectly-passed value types, and so on. The description of the lowered signature is intended to provide sufficient information for doing so, but will likely require tweaking.

At present, this new code is not integrated in the main code path for jextract-swift. Once it hits feature parity, we'll enable it.

…l` func

Start implementing a more complete and formal lowering from an arbitrary
Swift function to a `@_cdecl`-compatible thunk that calls that function.
This is set up in stages more akin to what you'd see in a compiler:

1. Resolve the syntax trees for the function into a more semantic
representation, for example resolving type names to nominal type
declarations. This includes a simplistic implementation of a symbol
table so we can resolve arbitrary type names.
2. Lower the semantic representation of each function parameter
(including self). How we do this varies based on type:
  * Value types (struct / enum) are passed indirectly via
    Unsafe(Mutable)RawPointer, using a mutable pointer when the
    corresponding parameter is inout.
  * Class / actor types are passed directly via UnsafeRawPointer.
  * Swift types that map to primitive types (like Swift.Int32) in
    passed directly, no translation required.
  * Tuple types are recursively "exploded" into multiple parameters.
  * Unsafe*BufferPointer types are "exploded" into a pointer and count.
  * Typed unsafe pointers types are passed via their raw versions.
3. Lower returns similarly to parameters, using indirect mutable
   parameters for the return when we can't return directly.
4. Render the lowered declaration into a FunctionDeclSyntax node,
   which can be modified by the client.

At present, we aren't rendering the bodies of these thunks, which need
to effectively undo the transformations described in (3) and (4). For
example, reconstituting a tuple from disparate arguments,
appropriately re-typing and loading from indirectly-passed value
types, and so on. The description of the lowered signature is intended
to provide sufficient information for doing so, but will likely
require tweaking.

At present, this new code is not integrated in the main code path for
jextract-swift. Once it hits feature parity, we'll enable it.
@DougGregor
Copy link
Member Author

I'm going to merge this and continue iterating.

@DougGregor DougGregor merged commit cb4fa3d into swiftlang:main Jan 23, 2025
12 checks passed
@DougGregor DougGregor deleted the cdecl-lowering branch January 23, 2025 18:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant