Handling unsigned numbers better in jextract #333
Conversation
ktoso
force-pushed
the
wip-unsigned
branch
3 times, most recently
from
4b92e65 to
e998244
Compare
ktoso
changed the title
| /// Specifically negative values of a `@Unchecked long` must be interpreted carefully as | ||
| /// a value larger than the Long.MAX_VALUE can represent in Java. You can use `org.swift.swiftkit.core.primitives` | ||
| /// utility classes to work with such unsigned values in Java. | ||
| case annotate |
There was a problem hiding this comment.
That's our default mode, it's also similar to what OpenJDK jextract does (we add the annotation, jextract itself does nothing)
| @Unsigned | ||
| public static int unsignedLong(@Unsigned long first, @Unsigned int second) { | ||
| return swiftjava_SwiftModule_unsignedLong_first_second.call(first, second); | ||
| } |
There was a problem hiding this comment.
Showcase of the default extract mode -- we don't do any conversions, but we annotate the types for easier discovery in IDEs
| @@ -0,0 +1,69 @@ | |||
| //===----------------------------------------------------------------------===// | |||
There was a problem hiding this comment.
All the primitives types are vendored Guava types.
TBD if we'd like to may be just roll our own entirely or just make jextract emit code which assumes you'll bring your own Guava perhaps...
|
I'm still on the fence about the I'm gonna sleep over this change and decide that to do about the guava types -- perhaps remove them for now, until we truly want them after all. |
This reverts commit c7499cc.
Resolves #307
This introduces
@Unsigned longand friends importing as well as an opt-in mode to import unsigned types as Guava'sUnsignedIntegerand friends which is only available for FFM right now.