Skip to content

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