Conversation
- bugfix to prevent a potential Arc double free in async code if both the called function and the error handle threw.
Need another thorough once over of the required changes.
- added external type support - fixed external errors, got rid of workaround - switched to JNA direct mapping - added config option omit_checksums - still no defaults even though others expanded default support
Needs some more work on proc macro cases and probably more test cases
This prevents bugs like the few we've had so far where a type wasn't imported because it wasn't added to the specific template where something was used. It also eliminates the possibility of collisions with enum variant classes names.
it may be a bit more robust with edge cases like external types
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against 7889de9 |
giarc3
approved these changes
Mar 23, 2026
coltfred
approved these changes
Mar 23, 2026
Member
coltfred
left a comment
coltfred
left a comment
There was a problem hiding this comment.
Couple variables that should be renamed back to their non _ names. Otherwise nothing stuck out to me.
src/templates/Async.java
Outdated
| } | ||
| } catch (Exception e) { | ||
| future.completeExceptionally(e); | ||
| } catch (java.lang.Exception _e) { |
Member
There was a problem hiding this comment.
You're using this, so it seems like e would be a fine name?
Member
Author
There was a problem hiding this comment.
This was from a bug on the Kotlin side where templated code contained user defined variable names, so the names could conflict. I went through again though and tried to make sure everywhere it was being done it actually could be with user params (I think), made those more explicit _uniffi_ex and reset the rest of things this had been done to.
* Use primitive arrays for better ergonomics/performance where possible. Special cases for primitives in the same vein as byte arrays, any compound types will still be List-based * Sort cargo
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Because changing to JNA direct mapping required moving to primitives in some places, I also fixed #22 in this, which is a breaking change (it was already breaking due to required uniffi changes). I removed the dead
literalcode, as it was only for defaults in Kotlin, and trying to come up with something for defaults after the new uniffi versions added even more support for it clarified that we weren't going to add default support anytime soon.Fixes #46, fixes #33, fixes #25, fixes #37
Unblocks IronCoreLabs/ironcore-alloy#288, will require a breaking change there.
java.langtype use in templates to simplify imports and avoid potential name collisionsomit_checksumsconfig option, see the kotlin doc about it.renameconfig option, see the docs.Breaking
--lib-fileand--libraryCLI generator options removed, they're both now automatically detected by uniffiint,long,boolean) instead of boxed types (Integer,Long,Boolean) for non-optional primitive parameters and return typesint,long,boolean, etc.) instead of boxed types (Integer,Long,Boolean) for non-optional primitive parameters, return types, and record fields. Optional primitives and primitives in generic contexts (e.g.,List<Integer>,CompletableFuture<Integer>) still use boxed types as required by Java.