Swift external type module config #1404
Open
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
External types require that one swift source file can use the
FfiConverter from another source file. This means that the read/write
functions can't input a Reader/Writer class:
- If the class is fileprivate, then this means the read/write methods
must also be fileprivate since they're inputting that type, but this
would totally prevent external types from working
- If the class is internal/public, we'll get compile errors since both
source files will try define the type.
Instead, read/write now input standard swift types, which allow them to
be shared between different source files.
"Handle" is a common name that's likely to cause name conflicts with user-defined types. This is exactly what happened when I tried to run the ext-types tests, which include a type named "Handle".
This code assumes that all generate files will be compiled into a single module, which makes external type support quite trivial. - Updated the swift testing code to handle multiple UDL files. - Made the custom type, enum, object, and record, FfiConverters public to allow them to be used with external types. - Made the FfiConverter methods public. I didn't make the protocols themselves public, since that would result in duplicate definitions when different UniFFI-generated swift files were linked together, but I did make each individual method public. - Added Swift external types tests. - Fixed a bug in the CustomType template. I'm pretty sure we should be using `type_ffi_lowered` instead of `ffi_type_name` there since it's Swift code rather than a C header file. - Added docs for configuring external types
Added support for build processes where each generated `.swift` file is compiled into its own module rather than compiling all files together. This means that we need imports to make external types work. - Added test fixture and updated the testing code to test this - Added config code to allow the user to choose their mode - Updated the docs to describe the config options
|
Are there any plans to merge this? I think it would really help to make it a lot simpler to namespace and organise generated swift code. it seems very primitive to have to put everything in a single namespace |
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.
This is based off of #1389. Let's merge that first. Here are the changes compared to that one:
Added support for build processes where each generated .swift file is compiled into its own module rather than compiling all files together. This means that we need imports to make external types work.