Bytes type and coverall test fixture #16
Conversation
Still need to complete coverall tests
|
|
||
| @Override | ||
| public long allocationSize(byte[] value) { | ||
| return 4L + (long)value.length; |
There was a problem hiding this comment.
length always 32 bits, even on 64 bit architectures? Looks like Java doesn't have sizeof(), so doing something different would probably suck anyway.
There was a problem hiding this comment.
The return value from Java for length is always an int regardless of arch/JVM. The actual max size of the array is JVM/arch dependant, but pretty sure it's always within int max.
| this((Pointer){%- call java::to_ffi_call(cons) -%}); | ||
| } | ||
| {%- endif %} | ||
| {%- when None %} | ||
| {%- endmatch %} | ||
|
|
||
| @Override | ||
| public void destroy() { | ||
| public synchronized void close() { |
There was a problem hiding this comment.
Since this is close() instead of destroy(), should it be wasClosed instead of wasDestroyed? Maybe wasDestroyed is fine, since it looks like it does destroy the fields when closing.
There was a problem hiding this comment.
Yeah it's a bit of both. close is the Java parlance and the Java interface we've implemented, but destroy is the common-across-bindgens uniffi word for it.
| public RustBuffer.ByValue getValue() { | ||
| Pointer pointer = this.getPointer(); | ||
| RustBuffer.ByValue value = new RustBuffer.ByValue(); | ||
| value.writeField("capacity", pointer.getLong(0)); |
There was a problem hiding this comment.
And the Rust ones are always 64 bits for capacity and length, regardless of architecture?
There was a problem hiding this comment.
This is a construct just for usage with uniffi, so yeah the capacity and length is always 64 bit.
* First pass at async file, still need futures * Futures test passed! I don't believe it... need some more complex tests * Update src/templates/UniffiHandleMap.java Co-authored-by: Bob Wall <[email protected]> * Update src/templates/UniffiHandleMap.java Co-authored-by: Bob Wall <[email protected]> * Checkpointing to update another branch * Going to require implementing callbacks anyway * So close to working async_traits Right now `CallbackTemplate.java` isn't being included in the generation, causing all build failures * One compilation error away... from probably the next batch of compilation errors! * Compiles, runtime error and need to fill out tests * Structures don't allow boxed type class fields need to make everything primitives if possible. If not, need to make primitives around structures. * Appropriate documentation is important. Structures require a no-args constructor in almost all cases. The Kotlin one happened to be working because all args were defaultable, which from the Java view works as a no-args constructor. Nothing about this is mentioned in the Structure or JNA documentation. * Sooooooo close. Something going on with cancellation looks like it's the cause of the only remaining failures (commented out). * Only cancellation failing Async callbacks weren't waiting on `get` correctly. Once that was fixed needed to unwrap `ExecutionException`s so they could be passed to Rust callbacks correctly. * Normal future cancellation fixed. * Fixed trait future cancellation too * Clean up some TODOs after PR comment pass * What if CI just needs more time? * Add a little more info to assert fail * Only run the failing test * Touch to rebuild * Add all tests back in * Bytes type and coverall test fixture (#16) * Passing tests, coverall generation working Still need to complete coverall tests * Checkpointing because I don't want to lose it * Finished all coverall tests * rogue println --------- Co-authored-by: Bob Wall <[email protected]> Co-authored-by: Colt Frederickson <[email protected]>
Switched from
DisposabletoAutoClosable. Big difference is thatAutoClosablethrows Exceptionwhich makes it slightly more annoying in some use cases. It allows us to usetry-with-resourcesthough to make sure things that need to get destroyed do get destroyed. We can't inline functions like Kotlin is doing withdestroyforDisposable, so we have to hold a strong reference to be able todestroysomething after a block of code, which negates a bit of the point.Disposable could be added back in the future (or in addition to AutoClosable) if necessary, but looking through the Rust code I didn't see anywhere a
destroywas being presented from that side or anything.Writing the coverall tests did catch a few edge cases that were fixed in this PR.