June 2023 - jextract-dev

RFR: 7903239: ofAddress factory of function pointer type is wrong for struct returns
by Marko 02 Jan '24

02 Jan '24

When generating the lambda inside the `ofAddress` factory, it is missing the `SegmentAllocator` needed when the function returns a struct. This is [implemented for regular functions](https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2…, but not for function pointers. ------------- Commit messages: - 7903239: ofAddress factory of function pointer type is wrong for struct returns Changes: https://git.openjdk.org/jextract/pull/58/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=58&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903239 Stats: 47 lines in 3 files changed: 44 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/58.diff Fetch: git fetch https://git.openjdk.org/jextract pull/58/head:pull/58 PR: https://git.openjdk.org/jextract/pull/58

3 11

RFR: Add path independence
by Per Minborg 02 Jan '24

02 Jan '24

This small PR incorporated feedback from the original PR: https://github.com/openjdk/jextract/pull/66 made after it was integrated. ------------- Commit messages: - Add path independence Changes: https://git.openjdk.org/jextract/pull/68/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=68&range=00 Stats: 10 lines in 4 files changed: 2 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jextract/pull/68.diff Fetch: git fetch https://git.openjdk.org/jextract pull/68/head:pull/68 PR: https://git.openjdk.org/jextract/pull/68

5 7

RFR: Add Dockerfile, zero-dep reproducible builds
by Gavin Ray 02 Jan '24

02 Jan '24

As title says, adds a Dockerfile that will fetch all necessary deps and build `jextract` for you on Ubuntu 22.10 It would be nice if some official JDK organization could put this on their Dockerhub, so that users could just do: $ docker run --rm -it openjdk/jextract:latest I've pushed it to my personal Dockerhub, so if anyone would like to test it out, you can use the README directions but prepend `gavinray/` before the image name: $ echo "struct Foo { int a; long b; }; int use_foo(struct Foo foo);" >> sample.h $ docker run --rm -it -v ${PWD}:/tmp/jextract \ gavinray/jextract:latest \ -I /tmp/jextract \ --source \ -l libfoo \ --output /tmp/jextract/generated \ --target-package com.example \ ------------- Commit messages: - Add Dockerfile, zero-dep reproducible builds Changes: https://git.openjdk.org/jextract/pull/74/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=74&range=00 Stats: 75 lines in 2 files changed: 75 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jextract/pull/74.diff Fetch: git fetch https://git.openjdk.org/jextract pull/74/head:pull/74 PR: https://git.openjdk.org/jextract/pull/74

3 6

RFR: Add third-party sample list to README, populate with java-vulkan.
by Michael Ennen 02 Jan '24

02 Jan '24

I made a more complex example (1000 lines, mostly because setting up a boilerplate Vulkan program is super lengthy) of using jextract on Vulkan and Win32 APIs. I think it may be too lengthy and too much of a maintenance burden to commit to the `/samples` directory, so I thought maybe including a section on third-party samples would be better. If this is not something you want to entertain that's totally understandable, but thought I would put it out there a bigger sample that interfaces with a pretty complex API may be helpful to others. ------------- Commit messages: - Add third-party sample list to README, populate with java-vulkan. Changes: https://git.openjdk.org/jextract/pull/93/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=93&range=00 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/93.diff Fetch: git fetch https://git.openjdk.org/jextract pull/93/head:pull/93 PR: https://git.openjdk.org/jextract/pull/93

3 3

jextract C++ support
by Rel 24 Sep '23

24 Sep '23

Hi, I would like to know how to participate in C++ support for jextract. Watching Project Panama video (https://inside.java/2023/04/18/levelup-panama/) Paul mentioned that C++ is in the plans. Do we have someone working on it already so I can syncup on what is the plan and where I can help? In particular: - will it be part of jextract or may be jextract++? - will it use clang or something else? if clang then which interface https://clang.llvm.org/docs/Tooling.html There are many things to be done for C++ support but if I pick the most basic like symbols, in C++ they are mangled so current jextract linking logic will need to be changed. Do you think modifying NameMangler to store those mangled C++ symbols will be the right approach? Regards,

4 15

RFR: Update jextract/panama branch to track JDK 22
by Maurizio Cimadamore 16 Jun '23

16 Jun '23

This PR contains some initial changes to enable jextract support for the latest Panama repo (and JDK 22 in general). It contains the usual updates to source, build and readme files (e.g. to replace jdk21 with jdk22). On top of that there are some changes to support the latest API changes in the Panama repo such as: * removal of implicit sequence layout factory * renaming of XYZUtf8String -> XYZString ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jextract/pull/123/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=123&range=00 Stats: 39 lines in 19 files changed: 1 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jextract/pull/123.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/123/head:pull/123 PR: https://git.openjdk.org/jextract/pull/123

2 3

RFR: 7903485 Windows.h fails to extract on jextract/panama
by Maurizio Cimadamore 12 Jun '23

12 Jun '23

This patch fixes a number of issues I discovered while trying to extract Windows.h on a recent jextract: * the size of `long double` layout is wrong. This means that if a struct with a field of that type is declared, StructLayoutComputer will fail (as it will see a size != expected size reported by clang) * There are cases where, also for unsupported layouts, we end up creating function descriptors with things containing padding. This is caused by the fact that the check for unsupported layouts in functions is performed *after* the creation of the function descriptor. * Sometimes libclang reports field cursors in an out-of-order fashion. I have not been able to pinpoint the exact cause, as all my attempts to create a reduced test case failed. When this behavior occurs, jextract ends up generating extra fields and padding. I believe this behavior has always been there, but now brought to the fore by the new eager checks. * A change in behavior of recent libclang causes `cursor.spelling()` to return non-empty strings (see https://github.com/llvm/llvm-project/issues/58429) * A quality of life fix, to generate "sensible" warnings when variadic callbacks are found ------------- Commit messages: - Strengthen TypeImpl - Make TypeImpl return empty optional for non-sensical layouts - Initial push Changes: https://git.openjdk.org/jextract/pull/122/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=122&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903485 Stats: 65 lines in 8 files changed: 31 ins; 19 del; 15 mod Patch: https://git.openjdk.org/jextract/pull/122.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/122/head:pull/122 PR: https://git.openjdk.org/jextract/pull/122

2 13