Initialize VTables for external types (#2343) #2367
Merged
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
bendk
force-pushed
the
push-ytonspxzsszq
branch
4 times, most recently
from
2176b68 to
c365982
Compare
bendk
changed the title
|
does it need Python and Kotlin too? |
|
The tests look good to me. I agree with @mhammond that it might be good to cover other languages. I think the same issue happens on Kotlin, too. |
bendk
force-pushed
the
push-ytonspxzsszq
branch
from
c365982 to
76767ee
Compare
|
I didn't think Python or Kotlin needed this, but when I wrote the tests I realized that we did have the same bug in Kotlin. Added some test cases and updated the kotlin code to deal with this. |
bendk
force-pushed
the
push-ytonspxzsszq
branch
from
76767ee to
602b715
Compare
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.
Fixed a tricky case from Swift: Because of it's C lineage, it doesn't have a way to run initialization code when the module is imported so instead it runs a one-time initialization function the first time a FFI call is run. This system failed when external types were used before the external module ever made an FFI call. I believe this is Swift only, but it might affect other C-like external bindings as well.
@crazytonyli thanks for the great test case for this, I shrunk it down to a mimimal test and added it to the existing fixture. When I rebase your test suite on top of this and run it with
ISSUE_2343=1 cargo test --package uniffi-fixture-ext-types-sub-libit passes. I don't think we need the all of the tests, but tell me if you think the other ones are still worth adding.