From nbenalla at openjdk.org  Wed Sep  3 15:53:07 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 3 Sep 2025 15:53:07 GMT
Subject: RFR: 7904073: Derive required symbols from client code to minimize
 generated bindings
Message-ID: <jVAYvet0rDw0r7iV1B_FzukKfPBC1Bvxb8lv7b1IeCE=.91e3c8f7-10ea-4fe9-a7b2-b7fda357fd07@github.com>

Please review this change to add a small sample that extracts full bindings once, scans the compiled client classes to collect actually referenced symbols, filters the includes list, and re-runs jextract to produce a slim binding set.

-------------

Commit messages:
 - add new sample

Changes: https://git.openjdk.org/jextract/pull/288/files
  Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=288&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904073
  Stats: 183 lines in 7 files changed: 182 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/288.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/288/head:pull/288

PR: https://git.openjdk.org/jextract/pull/288

From nbenalla at openjdk.org  Tue Sep  9 08:45:11 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 9 Sep 2025 08:45:11 GMT
Subject: RFR: 7903947: Access to function pointers  in structs could be
 streamlined
In-Reply-To: <Vfw0V_V_I98uOi-_3BGDeWrCpVLKvgtkwmBbyh1lIS4=.0fe07f1e-ce13-448f-ac2d-4404e75a408c@github.com>
References: <Vfw0V_V_I98uOi-_3BGDeWrCpVLKvgtkwmBbyh1lIS4=.0fe07f1e-ce13-448f-ac2d-4404e75a408c@github.com>
Message-ID: <JQxHLmn12Dl70nHPEsEdM0ts6X8PO6MTWaDj8_7BWRQ=.84ec076e-bf24-4b69-824b-29e8de21fe9e@github.com>

On Wed, 23 Jul 2025 12:37:47 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to add a new option where you can generate an direct invoker methods. This feature is intended to be used on structs that are just a collection of functions we had like to call.
> 
> If this feature is used, we remove the getter to avoid name collisions as we assume this is similar to an interface.
> 
> Changes to `GUIDE.md` have been intentionally left out from this initial patch to make reviews easier.
> 
> 
> struct Foo {
>     struct Bar (*a)(void);
>     struct Bar (*b)(int);
> };
> 
> 
> Before 
> 
> 
> var foo = alloc_callback_h.foo();
> 
> var barA = Foo.a.invoke(Foo.a(foo), arena);
> var barB = Foo.b.invoke(Foo.b(foo), arena, 100);
> 
> 
> After 
> 
> 
> var foo = alloc_callback_h.foo();
> 
> var barA = Foo.a(foo, arena);
> var barB = Foo.b(foo, arena, 100);

Keep Alive

-------------

PR Comment: https://git.openjdk.org/jextract/pull/287#issuecomment-3269564444

From manuel.bleichenbacher at gmail.com  Wed Sep 10 11:46:18 2025
From: manuel.bleichenbacher at gmail.com (Manuel Bleichenbacher)
Date: Wed, 10 Sep 2025 13:46:18 +0200
Subject: Function pointers and GraalVM
Message-ID: <CAA7F5jJXVb3fRs23WhihVpJsFr2H=zSXLxqqn_H7WkH8WnagqA@mail.gmail.com>

Hi jextract team

I've been playing with the upcoming GraalVM 25 and its support for FFM. But
I've run into an issue with code generated by jextract related to function
pointers: it always instantiates both the downcall and upcall method
handles, independent of which one is actually used. In my case, I would
only need the downcall handle. The unnecessary upcall handle depends on
another method ("apply") that GraalVM has correctly identified to never be
called and is thus omitted from the native image. As a result, the
application crashes at run-time.

It wouldn't be such a problem if I was dealing with one or two function
pointers. Then I would manually create the required FFM code with downcall
handles only. However, I'm dealing with COM interfaces and the macOS IOKit
version thereof:

*typedef* *struct* IOUSBInterfaceStruct942 {

    IUNKNOWN_C_GUTS;

    IOReturn (*CreateInterfaceAsyncEventSource)(*void* **self*,
CFRunLoopSourceRef *source);

    CFRunLoopSourceRef (*GetInterfaceAsyncEventSource)(*void* **self*);

    IOReturn (*CreateInterfaceAsyncPort)(*void* **self*, mach_port_t *port);

    mach_port_t (*GetInterfaceAsyncPort)(*void* **self*);

    IOReturn (*USBInterfaceOpen)(*void* **self*);

    IOReturn (*USBInterfaceClose)(*void* **self*);

    IOReturn (*GetInterfaceClass)(*void* **self*, UInt8 *intfClass);

    IOReturn (*GetInterfaceSubClass)(*void* **self*, UInt8 *intfSubClass);

    IOReturn (*GetInterfaceProtocol)(*void* **self*, UInt8 *intfProtocol);

    IOReturn (*GetDeviceVendor)(*void* **self*, UInt16 *devVendor);

    ...

These are structs that almost exclusively consist of function pointers. In
the case of IOKit, the two main ones consist of 40 and 50 function pointers.

Am I correct that there is currently no way to suppress the generation of
upcall method handles?

Are there any plans to to make the jextract generated code work well with
GraalVM?

Regards
Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250910/8e259c3d/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Wed Sep 10 12:24:56 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 10 Sep 2025 13:24:56 +0100
Subject: Function pointers and GraalVM
In-Reply-To: <CAA7F5jJXVb3fRs23WhihVpJsFr2H=zSXLxqqn_H7WkH8WnagqA@mail.gmail.com>
References: <CAA7F5jJXVb3fRs23WhihVpJsFr2H=zSXLxqqn_H7WkH8WnagqA@mail.gmail.com>
Message-ID: <e247ece8-9c5c-4f20-b19b-d858fec0b780@oracle.com>

Seems related to this?

https://git.openjdk.org/jextract/pull/287

It would be very helpful if you could try the option in that PR (you 
would need to build jextract manually) and see if that improves the 
situation.

Cheers
Maurizio

On 10/09/2025 12:46, Manuel Bleichenbacher wrote:
> Hi jextract team
>
> I've been playing with the upcoming GraalVM 25 and its support for 
> FFM. But I've run into an issue with code generated by jextract 
> related to function pointers: it always instantiates both the downcall 
> and upcall method handles, independent of which one is actually used. 
> In my case, I would only need the downcall handle. The unnecessary 
> upcall handle depends on another method ("apply") that GraalVM has 
> correctly identified to never be called and is thus omitted from the 
> native image. As a result, the application crashes at run-time.
>
> It wouldn't be such a problem if I was dealing with one or two 
> function pointers. Then I would manually create the required FFM code 
> with downcall handles only. However, I'm dealing with COM interfaces 
> and the macOS IOKit version thereof:
>
> *typedef**struct*IOUSBInterfaceStruct942{
>
> IUNKNOWN_C_GUTS;
>
> IOReturn (*CreateInterfaceAsyncEventSource)(*void* **self*, 
> CFRunLoopSourceRef *source);
>
> CFRunLoopSourceRef (*GetInterfaceAsyncEventSource)(*void* **self*);
>
> IOReturn (*CreateInterfaceAsyncPort)(*void* **self*, mach_port_t *port);
>
> mach_port_t (*GetInterfaceAsyncPort)(*void* **self*);
>
> IOReturn (*USBInterfaceOpen)(*void* **self*);
>
> IOReturn (*USBInterfaceClose)(*void* **self*);
>
> IOReturn (*GetInterfaceClass)(*void* **self*, UInt8 *intfClass);
>
> IOReturn (*GetInterfaceSubClass)(*void* **self*, UInt8 *intfSubClass);
>
> IOReturn (*GetInterfaceProtocol)(*void* **self*, UInt8 *intfProtocol);
>
> IOReturn (*GetDeviceVendor)(*void* **self*, UInt16 *devVendor);
>
> ? ...
>
>
> These are structs that almost exclusively consist of function 
> pointers. In the case of IOKit, the two main ones consist of 40 and 50 
> function pointers.
>
> Am I correct that there is currently no way to suppress the generation 
> of upcall method handles?
>
> Are there any plans to to make the jextract generated code work well 
> with GraalVM?
>
> Regards
> Manuel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250910/fd1b6be0/attachment.htm>

From manuel.bleichenbacher at gmail.com  Wed Sep 10 13:12:53 2025
From: manuel.bleichenbacher at gmail.com (Manuel Bleichenbacher)
Date: Wed, 10 Sep 2025 15:12:53 +0200
Subject: Function pointers and GraalVM
In-Reply-To: <e247ece8-9c5c-4f20-b19b-d858fec0b780@oracle.com>
References: <CAA7F5jJXVb3fRs23WhihVpJsFr2H=zSXLxqqn_H7WkH8WnagqA@mail.gmail.com>
 <e247ece8-9c5c-4f20-b19b-d858fec0b780@oracle.com>
Message-ID: <CAA7F5jL7Q7vHFjTq0b8U-uzG9rU5MgWxo1oCN__B0ykMp1n8rw@mail.gmail.com>

Hi Maurizio

The pull request solves something different. It simplifies invoking
function pointers that are part of a struct. For COM interfaces and similar
constructs, this is quite useful.

However, the code for the upcall and downcall handle hasn't changed. They
are still static fields of an inner class. So they will always be
instantiated as a pair.

But it might be useful to go one step further with this pull request and
not emit the upcall (method handle, function interface, "apply" method) if
the "functional" option is specified. Or even consider emitting code like
my Windows API Generator does for COM interfaces (see
https://github.com/manuelbl/WindowsApiGenerator/blob/main/docs/com_interfaces.md).
It doesn't create an interface for each function pointer, but a single one
for the entire struct, separate implementation classes for downcalls
(calling a COM interface) and upcalls (implementing COM interfaces).

By the way: the current pull request has a further problem. I generates
code that doesn't compile. Depending on the arguments of the function
pointer, the setter and the invoker method have the same arguments and
clash.

Regards
Manuel


Am Mi., 10. Sept. 2025 um 14:25 Uhr schrieb Maurizio Cimadamore <
maurizio.cimadamore at oracle.com>:

> Seems related to this?
>
> https://git.openjdk.org/jextract/pull/287
>
> It would be very helpful if you could try the option in that PR (you would
> need to build jextract manually) and see if that improves the situation.
>
> Cheers
> Maurizio
> On 10/09/2025 12:46, Manuel Bleichenbacher wrote:
>
> Hi jextract team
>
> I've been playing with the upcoming GraalVM 25 and its support for FFM.
> But I've run into an issue with code generated by jextract related to
> function pointers: it always instantiates both the downcall and upcall
> method handles, independent of which one is actually used. In my case, I
> would only need the downcall handle. The unnecessary upcall handle depends
> on another method ("apply") that GraalVM has correctly identified to never
> be called and is thus omitted from the native image. As a result, the
> application crashes at run-time.
>
> It wouldn't be such a problem if I was dealing with one or two function
> pointers. Then I would manually create the required FFM code with downcall
> handles only. However, I'm dealing with COM interfaces and the macOS IOKit
> version thereof:
>
> *typedef* *struct* IOUSBInterfaceStruct942 {
>
>     IUNKNOWN_C_GUTS;
>
>     IOReturn (*CreateInterfaceAsyncEventSource)(*void* **self*,
> CFRunLoopSourceRef *source);
>
>     CFRunLoopSourceRef (*GetInterfaceAsyncEventSource)(*void* **self*);
>
>     IOReturn (*CreateInterfaceAsyncPort)(*void* **self*, mach_port_t
> *port);
>
>     mach_port_t (*GetInterfaceAsyncPort)(*void* **self*);
>
>     IOReturn (*USBInterfaceOpen)(*void* **self*);
>
>     IOReturn (*USBInterfaceClose)(*void* **self*);
>
>     IOReturn (*GetInterfaceClass)(*void* **self*, UInt8 *intfClass);
>
>     IOReturn (*GetInterfaceSubClass)(*void* **self*, UInt8 *intfSubClass);
>
>     IOReturn (*GetInterfaceProtocol)(*void* **self*, UInt8 *intfProtocol);
>
>     IOReturn (*GetDeviceVendor)(*void* **self*, UInt16 *devVendor);
>
>     ...
>
> These are structs that almost exclusively consist of function pointers. In
> the case of IOKit, the two main ones consist of 40 and 50 function pointers.
>
> Am I correct that there is currently no way to suppress the generation of
> upcall method handles?
>
> Are there any plans to to make the jextract generated code work well with
> GraalVM?
>
> Regards
> Manuel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250910/465106db/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Wed Sep 10 15:49:57 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 10 Sep 2025 16:49:57 +0100
Subject: Function pointers and GraalVM
In-Reply-To: <CAA7F5jL7Q7vHFjTq0b8U-uzG9rU5MgWxo1oCN__B0ykMp1n8rw@mail.gmail.com>
References: <CAA7F5jJXVb3fRs23WhihVpJsFr2H=zSXLxqqn_H7WkH8WnagqA@mail.gmail.com>
 <e247ece8-9c5c-4f20-b19b-d858fec0b780@oracle.com>
 <CAA7F5jL7Q7vHFjTq0b8U-uzG9rU5MgWxo1oCN__B0ykMp1n8rw@mail.gmail.com>
Message-ID: <926c50ac-d8ea-4a9a-8e8d-4227839971f2@oracle.com>


On 10/09/2025 14:12, Manuel Bleichenbacher wrote:
> Hi Maurizio
>
> The pull request solves something different. It simplifies invoking 
> function pointers that are part of a struct. For COM interfaces and 
> similar constructs, this is quite useful.
>
> However, the code for the upcall and downcall handle hasn't changed. 
> They are still static fields of an inner class. So they will always be 
> instantiated as a pair.
>
> But it might be useful to go one step further with this pull request 
> and not emit the upcall (method handle, function interface, "apply" 
> method) if the "functional" option is specified.

Apologies -- that is what I assumed the changes in the PR did. I believe 
it should be possible to at least enhance the PR that way and then try 
things out. @Nizar could you please look into this?

I did something like this in our jextract/ONNX/Babylon experiment

https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/src/main/java/oracle/code/onnx/foreign/OrtApi.java

(as you can see there's no upcall handles there, as they were not needed).

> Or even consider emitting code like my Windows API Generator does for 
> COM interfaces (see 
> https://github.com/manuelbl/WindowsApiGenerator/blob/main/docs/com_interfaces.md 
> <https://urldefense.com/v3/__https://github.com/manuelbl/WindowsApiGenerator/blob/main/docs/com_interfaces.md__;!!ACWV5N9M2RV99hQ!IvvUYfukc401IJY8ml05l3Br5O2zP9NNaFN0JHeYgLetR8-G3vGu2SasWYB1phslKRoYTjaelHHiU5OcLIcPmfi7f8dQsqzrow$>). 
> It doesn't create an interface for each function pointer, but a single 
> one for the entire struct, separate implementation classes for 
> downcalls (calling a COM interface) and upcalls (implementing COM 
> interfaces).

I _think_ I did something like this in our jextract/ONNX/Babylon experiment

https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/src/main/java/oracle/code/onnx/foreign/OrtApi.java

(as you can see there's no interfaces and no upcall handles there, as 
they were not needed).

Is that similar to what you had in mind?

Maurizio

>
> By the way: the current pull request has a further problem. I 
> generates code that doesn't compile. Depending on the arguments of the 
> function pointer, the setter and the invoker method have the same 
> arguments and clash.
>
> Regards
> Manuel
>
>
> Am Mi., 10. Sept. 2025 um 14:25?Uhr schrieb Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com>:
>
>     Seems related to this?
>
>     https://git.openjdk.org/jextract/pull/287
>
>     It would be very helpful if you could try the option in that PR
>     (you would need to build jextract manually) and see if that
>     improves the situation.
>
>     Cheers
>     Maurizio
>
>     On 10/09/2025 12:46, Manuel Bleichenbacher wrote:
>>     Hi jextract team
>>
>>     I've been playing with the upcoming GraalVM 25 and its support
>>     for FFM. But I've run into an issue with code generated by
>>     jextract related to function pointers: it always instantiates
>>     both the downcall and upcall method handles, independent of which
>>     one is actually used. In my case, I would only need the downcall
>>     handle. The unnecessary upcall handle depends on another method
>>     ("apply") that GraalVM has correctly identified to never be
>>     called and is thus omitted from the native image. As a result,
>>     the application crashes at run-time.
>>
>>     It wouldn't be such a problem if I was dealing with one or two
>>     function pointers. Then I would manually create the required FFM
>>     code with downcall handles only. However, I'm dealing with COM
>>     interfaces and the macOS IOKit version thereof:
>>
>>     *typedef**struct*IOUSBInterfaceStruct942{
>>
>>     IUNKNOWN_C_GUTS;
>>
>>     IOReturn (*CreateInterfaceAsyncEventSource)(*void* **self*,
>>     CFRunLoopSourceRef *source);
>>
>>     CFRunLoopSourceRef (*GetInterfaceAsyncEventSource)(*void* **self*);
>>
>>     IOReturn (*CreateInterfaceAsyncPort)(*void* **self*, mach_port_t
>>     *port);
>>
>>     mach_port_t (*GetInterfaceAsyncPort)(*void* **self*);
>>
>>     IOReturn (*USBInterfaceOpen)(*void* **self*);
>>
>>     IOReturn (*USBInterfaceClose)(*void* **self*);
>>
>>     IOReturn (*GetInterfaceClass)(*void* **self*, UInt8 *intfClass);
>>
>>     IOReturn (*GetInterfaceSubClass)(*void* **self*, UInt8
>>     *intfSubClass);
>>
>>     IOReturn (*GetInterfaceProtocol)(*void* **self*, UInt8
>>     *intfProtocol);
>>
>>     IOReturn (*GetDeviceVendor)(*void* **self*, UInt16 *devVendor);
>>
>>     ? ...
>>
>>
>>     These are structs that almost exclusively consist of function
>>     pointers. In the case of IOKit, the two main ones consist of 40
>>     and 50 function pointers.
>>
>>     Am I correct that there is currently no way to suppress the
>>     generation of upcall method handles?
>>
>>     Are there any plans to to make the jextract generated code work
>>     well with GraalVM?
>>
>>     Regards
>>     Manuel
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250910/80415163/attachment-0001.htm>

From manuel.bleichenbacher at gmail.com  Wed Sep 10 19:30:10 2025
From: manuel.bleichenbacher at gmail.com (Manuel Bleichenbacher)
Date: Wed, 10 Sep 2025 21:30:10 +0200
Subject: Function pointers and GraalVM
In-Reply-To: <926c50ac-d8ea-4a9a-8e8d-4227839971f2@oracle.com>
References: <CAA7F5jJXVb3fRs23WhihVpJsFr2H=zSXLxqqn_H7WkH8WnagqA@mail.gmail.com>
 <e247ece8-9c5c-4f20-b19b-d858fec0b780@oracle.com>
 <CAA7F5jL7Q7vHFjTq0b8U-uzG9rU5MgWxo1oCN__B0ykMp1n8rw@mail.gmail.com>
 <926c50ac-d8ea-4a9a-8e8d-4227839971f2@oracle.com>
Message-ID: <CAA7F5jL_Ee5Rmr64DxywNJ0U2zFnbD8KfStxRPuQ38NMNa-7LA@mail.gmail.com>

Hi Maurizio

Yes, your experiment code is exactly what would be needed. It has the
simple static invoker method (as proposed by the pull requests) and it does
not generate code for getter, setter and upcalls. It's probably all that is
needed for the "functional struct" use case.

Regards
Manuel


Am Mi., 10. Sept. 2025 um 17:50 Uhr schrieb Maurizio Cimadamore <
maurizio.cimadamore at oracle.com>:

>
> On 10/09/2025 14:12, Manuel Bleichenbacher wrote:
>
> Hi Maurizio
>
> The pull request solves something different. It simplifies invoking
> function pointers that are part of a struct. For COM interfaces and similar
> constructs, this is quite useful.
>
> However, the code for the upcall and downcall handle hasn't changed. They
> are still static fields of an inner class. So they will always be
> instantiated as a pair.
>
> But it might be useful to go one step further with this pull request and
> not emit the upcall (method handle, function interface, "apply" method) if
> the "functional" option is specified.
>
> Apologies -- that is what I assumed the changes in the PR did. I believe
> it should be possible to at least enhance the PR that way and then try
> things out. @Nizar could you please look into this?
>
> I did something like this in our jextract/ONNX/Babylon experiment
>
>
> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/src/main/java/oracle/code/onnx/foreign/OrtApi.java
>
> (as you can see there's no upcall handles there, as they were not needed).
>
> Or even consider emitting code like my Windows API Generator does for COM
> interfaces (see
> https://github.com/manuelbl/WindowsApiGenerator/blob/main/docs/com_interfaces.md
> <https://urldefense.com/v3/__https://github.com/manuelbl/WindowsApiGenerator/blob/main/docs/com_interfaces.md__;!!ACWV5N9M2RV99hQ!IvvUYfukc401IJY8ml05l3Br5O2zP9NNaFN0JHeYgLetR8-G3vGu2SasWYB1phslKRoYTjaelHHiU5OcLIcPmfi7f8dQsqzrow$>).
> It doesn't create an interface for each function pointer, but a single one
> for the entire struct, separate implementation classes for downcalls
> (calling a COM interface) and upcalls (implementing COM interfaces).
>
> I _think_ I did something like this in our jextract/ONNX/Babylon experiment
>
>
> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/src/main/java/oracle/code/onnx/foreign/OrtApi.java
>
> (as you can see there's no interfaces and no upcall handles there, as they
> were not needed).
>
> Is that similar to what you had in mind?
>
> Maurizio
>
>
> By the way: the current pull request has a further problem. I generates
> code that doesn't compile. Depending on the arguments of the function
> pointer, the setter and the invoker method have the same arguments and
> clash.
>
> Regards
> Manuel
>
>
> Am Mi., 10. Sept. 2025 um 14:25 Uhr schrieb Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com>:
>
>> Seems related to this?
>>
>> https://git.openjdk.org/jextract/pull/287
>>
>> It would be very helpful if you could try the option in that PR (you
>> would need to build jextract manually) and see if that improves the
>> situation.
>>
>> Cheers
>> Maurizio
>> On 10/09/2025 12:46, Manuel Bleichenbacher wrote:
>>
>> Hi jextract team
>>
>> I've been playing with the upcoming GraalVM 25 and its support for FFM.
>> But I've run into an issue with code generated by jextract related to
>> function pointers: it always instantiates both the downcall and upcall
>> method handles, independent of which one is actually used. In my case, I
>> would only need the downcall handle. The unnecessary upcall handle depends
>> on another method ("apply") that GraalVM has correctly identified to never
>> be called and is thus omitted from the native image. As a result, the
>> application crashes at run-time.
>>
>> It wouldn't be such a problem if I was dealing with one or two function
>> pointers. Then I would manually create the required FFM code with downcall
>> handles only. However, I'm dealing with COM interfaces and the macOS IOKit
>> version thereof:
>>
>> *typedef* *struct* IOUSBInterfaceStruct942 {
>>
>>     IUNKNOWN_C_GUTS;
>>
>>     IOReturn (*CreateInterfaceAsyncEventSource)(*void* **self*,
>> CFRunLoopSourceRef *source);
>>
>>     CFRunLoopSourceRef (*GetInterfaceAsyncEventSource)(*void* **self*);
>>
>>     IOReturn (*CreateInterfaceAsyncPort)(*void* **self*, mach_port_t
>> *port);
>>
>>     mach_port_t (*GetInterfaceAsyncPort)(*void* **self*);
>>
>>     IOReturn (*USBInterfaceOpen)(*void* **self*);
>>
>>     IOReturn (*USBInterfaceClose)(*void* **self*);
>>
>>     IOReturn (*GetInterfaceClass)(*void* **self*, UInt8 *intfClass);
>>
>>     IOReturn (*GetInterfaceSubClass)(*void* **self*, UInt8
>> *intfSubClass);
>>
>>     IOReturn (*GetInterfaceProtocol)(*void* **self*, UInt8
>> *intfProtocol);
>>
>>     IOReturn (*GetDeviceVendor)(*void* **self*, UInt16 *devVendor);
>>
>>     ...
>>
>> These are structs that almost exclusively consist of function pointers.
>> In the case of IOKit, the two main ones consist of 40 and 50 function
>> pointers.
>>
>> Am I correct that there is currently no way to suppress the generation of
>> upcall method handles?
>>
>> Are there any plans to to make the jextract generated code work well with
>> GraalVM?
>>
>> Regards
>> Manuel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250910/67747139/attachment.htm>

From varadam at openjdk.org  Thu Sep 11 06:57:03 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 11 Sep 2025 06:57:03 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct
Message-ID: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>

CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 

JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)

-------------

Commit messages:
 - CODETOOLS-7904079: Fix setting up length parameter for CXUnsavedFiles Struct

Changes: https://git.openjdk.org/jextract/pull/289/files
  Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904079
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/289/head:pull/289

PR: https://git.openjdk.org/jextract/pull/289

From varadam at openjdk.org  Thu Sep 11 07:03:13 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 11 Sep 2025 07:03:13 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v2]
In-Reply-To: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
Message-ID: <vv6pSGK59ITH3kKjCt1t5Xn2cDZ8rsW6Lv6wQYioWfk=.96395feb-314c-46da-913b-f9071b266787@github.com>

> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
> 
> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)

Varada M has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  CODETOOLS-7904079: Fix setting up length parameter for CXUnsavedFiles Struct

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/289/files
  - new: https://git.openjdk.org/jextract/pull/289/files/8e9388d0..798f0949

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jextract/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/289/head:pull/289

PR: https://git.openjdk.org/jextract/pull/289

From nbenalla at openjdk.org  Thu Sep 11 10:19:19 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 11 Sep 2025 10:19:19 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v2]
In-Reply-To: <vv6pSGK59ITH3kKjCt1t5Xn2cDZ8rsW6Lv6wQYioWfk=.96395feb-314c-46da-913b-f9071b266787@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <vv6pSGK59ITH3kKjCt1t5Xn2cDZ8rsW6Lv6wQYioWfk=.96395feb-314c-46da-913b-f9071b266787@github.com>
Message-ID: <UpJDwiwBAEc4k7JJTyhugQRckEGeycbC9EKg_3sdC2w=.4c16f565-9174-4aae-aa64-771816729f25@github.com>

On Thu, 11 Sep 2025 07:03:13 GMT, Varada M <varadam at openjdk.org> wrote:

>> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
>> 
>> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)
>
> Varada M has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   CODETOOLS-7904079: Fix setting up length parameter for CXUnsavedFiles Struct

Thanks for reporting this issue.

These files are generated automatically using jextract (https://github.com/openjdk/jextract/blob/master/updateclang/README.md), I'm not sure if we want to be manually updating these files.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/289#issuecomment-3279737532

From jvernee at openjdk.org  Thu Sep 11 11:27:10 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 11 Sep 2025 11:27:10 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v2]
In-Reply-To: <vv6pSGK59ITH3kKjCt1t5Xn2cDZ8rsW6Lv6wQYioWfk=.96395feb-314c-46da-913b-f9071b266787@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <vv6pSGK59ITH3kKjCt1t5Xn2cDZ8rsW6Lv6wQYioWfk=.96395feb-314c-46da-913b-f9071b266787@github.com>
Message-ID: <i69K0UIOqDum7G5tZEMxgFEhUn7_QrTg22yqNSxlmSI=.73946ef1-9625-4c0b-b795-5acb0d889a2e@github.com>

On Thu, 11 Sep 2025 07:03:13 GMT, Varada M <varadam at openjdk.org> wrote:

>> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
>> 
>> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)
>
> Varada M has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   CODETOOLS-7904079: Fix setting up length parameter for CXUnsavedFiles Struct

This seems to be the one field in the libclang library that uses the non-portable type `unsigned long`, instead of the `long long` that is used everywhere else. (https://clang.llvm.org/doxygen/structCXUnsavedFile.html)

The issue with writing a 64 bit value here is that the value will be out of bounds on Windows, where a `long` is only 32 bits. We should also update the initializer of `C_LONG` in `Index_h` so that it uses `Linker::cannonicalLayouts` which will return the right layout based on the platform.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/289#issuecomment-3280060668

From varadam at openjdk.org  Thu Sep 18 12:09:45 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 18 Sep 2025 12:09:45 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v3]
In-Reply-To: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
Message-ID: <AwAOCdmW4xdcwTdCoFiYTAN3cHtcdkxUr1mg0fqgAOw=.2d551acb-6397-4315-8aed-94f18ae670cf@github.com>

> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
> 
> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)

Varada M has updated the pull request incrementally with two additional commits since the last revision:

 - 7904079: Fix setting up length parameter for CXUnsavedFiles Struct
 - 7904079: Fix setting up length parameter for CXUnsavedFiles Struct

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/289/files
  - new: https://git.openjdk.org/jextract/pull/289/files/798f0949..f5fbbc36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=02
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=01-02

  Stats: 18 lines in 2 files changed: 16 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jextract/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/289/head:pull/289

PR: https://git.openjdk.org/jextract/pull/289

From varadam at openjdk.org  Thu Sep 18 12:17:48 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 18 Sep 2025 12:17:48 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v4]
In-Reply-To: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
Message-ID: <-N5iaFrhbqxN7PkTvDkc58gyHk0AVKuRuEsmieslH1c=.c755adce-4585-4cff-a1f6-b13e48cfa4cf@github.com>

> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
> 
> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  7904079: Fix setting up length parameter for CXUnsavedFiles Struct

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/289/files
  - new: https://git.openjdk.org/jextract/pull/289/files/f5fbbc36..812861a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=03
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/289/head:pull/289

PR: https://git.openjdk.org/jextract/pull/289

From varadam at openjdk.org  Thu Sep 18 12:17:50 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 18 Sep 2025 12:17:50 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v2]
In-Reply-To: <UpJDwiwBAEc4k7JJTyhugQRckEGeycbC9EKg_3sdC2w=.4c16f565-9174-4aae-aa64-771816729f25@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <vv6pSGK59ITH3kKjCt1t5Xn2cDZ8rsW6Lv6wQYioWfk=.96395feb-314c-46da-913b-f9071b266787@github.com>
 <UpJDwiwBAEc4k7JJTyhugQRckEGeycbC9EKg_3sdC2w=.4c16f565-9174-4aae-aa64-771816729f25@github.com>
Message-ID: <_HG-TU9MxQTivP_RvTYJQmO_CuSNeyHttwYZsmkbnMw=.caf5a7e3-9c83-41d1-9aa6-1a49fa04bd11@github.com>

On Thu, 11 Sep 2025 10:16:51 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Varada M has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   CODETOOLS-7904079: Fix setting up length parameter for CXUnsavedFiles Struct
>
> Thanks for reporting this issue.
> 
> These files are generated automatically using jextract (https://github.com/openjdk/jextract/blob/master/updateclang/README.md), I'm not sure if we want to be manually updating these files.

Thank you @nizarbenalla and @JornVernee for the review. 
I have updated the changes so that it uses Linker::cannonicalLayouts to return the right layout based on platform

-------------

PR Comment: https://git.openjdk.org/jextract/pull/289#issuecomment-3307124470

From jvernee at openjdk.org  Thu Sep 18 15:22:23 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 18 Sep 2025 15:22:23 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v4]
In-Reply-To: <-N5iaFrhbqxN7PkTvDkc58gyHk0AVKuRuEsmieslH1c=.c755adce-4585-4cff-a1f6-b13e48cfa4cf@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <-N5iaFrhbqxN7PkTvDkc58gyHk0AVKuRuEsmieslH1c=.c755adce-4585-4cff-a1f6-b13e48cfa4cf@github.com>
Message-ID: <uHUYaeVmb7ets9p40EXpAFayZwSEhWkkTteWNfxSaxI=.916381ac-1f01-4ddb-bba5-5bc0679f786a@github.com>

On Thu, 18 Sep 2025 12:17:48 GMT, Varada M <varadam at openjdk.org> wrote:

>> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
>> 
>> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7904079: Fix setting up length parameter for CXUnsavedFiles Struct

Thanks for the updates! Some more changes are needed though. Tests on Windows currently fail with a class cast exception when initializing the `CXUnsavedFile` class:


...
Caused by: java.lang.ClassCastException: class jdk.internal.foreign.layout.ValueLayouts$OfIntImpl cannot be cast to class java.lang.foreign.ValueLayout$OfLong (jdk.internal.foreign.layout.ValueLayouts$OfIntImpl and java.lang.foreign.ValueLayout$OfLong are in module java.base of loader 'bootstrap')
        at org.openjdk.jextract at 23/org.openjdk.jextract.clang.libclang.CXUnsavedFile.<clinit>(CXUnsavedFile.java:156)
        ... 39 more


I think it would be best to modify `CXUnsavedFile` to tweak the layout based on the size of `C_LONG`. Besides the changes I mentioned inline, I have the following changes locally to make this work:


diff --git a/src/main/java/org/openjdk/jextract/clang/libclang/CXUnsavedFile.java b/src/main/java/org/openjdk/jextract/clang/libclang/CXUnsavedFile.java
index 12d25de..a0ebb98 100644
--- a/src/main/java/org/openjdk/jextract/clang/libclang/CXUnsavedFile.java
+++ b/src/main/java/org/openjdk/jextract/clang/libclang/CXUnsavedFile.java
@@ -52,11 +52,20 @@ public class CXUnsavedFile {
         // Should not be called directly
     }
 
-    private static final GroupLayout $LAYOUT = MemoryLayout.structLayout(
-        Index_h.C_POINTER.withName("Filename"),
-        Index_h.C_POINTER.withName("Contents"),
-        Index_h.C_LONG.withName("Length")
-    ).withName("CXUnsavedFile");
+    private static final GroupLayout $LAYOUT = (switch (Index_h.C_LONG) {
+            case OfInt _ -> MemoryLayout.structLayout(
+                    Index_h.C_POINTER.withName("Filename"),
+                    Index_h.C_POINTER.withName("Contents"),
+                    Index_h.C_LONG.withName("Length"),
+                    MemoryLayout.paddingLayout(4)
+            );
+            case OfLong _ -> MemoryLayout.structLayout(
+                    Index_h.C_POINTER.withName("Filename"),
+                    Index_h.C_POINTER.withName("Contents"),
+                    Index_h.C_LONG.withName("Length")
+            );
+            default -> throw new IllegalStateException("Unhandled layout: " + Index_h.C_LONG);
+        }).withName("CXUnsavedFile");
 
     /**
      * The layout of this struct
@@ -153,7 +162,7 @@ public class CXUnsavedFile {
         struct.set(Contents$LAYOUT, Contents$OFFSET, fieldValue);
     }
 
-    private static final OfLong Length$LAYOUT = (OfLong)$LAYOUT.select(groupElement("Length"));
+    private static final ValueLayout Length$LAYOUT = (ValueLayout) $LAYOUT.select(groupElement("Length"));
 
     /**
      * Layout for field:
@@ -161,7 +170,7 @@ public class CXUnsavedFile {
      * unsigned long Length
      * }
      */
-    public static final OfLong Length$layout() {
+    public static final ValueLayout Length$layout() {
         return Length$LAYOUT;
     }
 
@@ -184,7 +193,11 @@ public class CXUnsavedFile {
      * }
      */
     public static long Length(MemorySegment struct) {
-        return struct.get(Length$LAYOUT, Length$OFFSET);
+        return switch (Length$LAYOUT) {
+            case OfInt l -> struct.get(l, Length$OFFSET);
+            case OfLong l -> struct.get(l, Length$OFFSET);
+            default -> throw new IllegalStateException("Unhandled layout: " + Length$LAYOUT);
+        };
     }
 
     /**
@@ -194,7 +207,11 @@ public class CXUnsavedFile {
      * }
      */
     public static void Length(MemorySegment struct, long fieldValue) {
-        struct.set(Length$LAYOUT, Length$OFFSET, fieldValue);
+        switch (Length$LAYOUT) {
+            case OfInt l -> struct.set(l, Length$OFFSET, Math.toIntExact(fieldValue));
+            case OfLong l -> struct.set(l, Length$OFFSET, fieldValue);
+            default -> throw new IllegalStateException("Unhandled layout: " + Length$LAYOUT);
+        }
     }
 
     /**


Please also update the copyright years of the edited files.

I'll see about getting the GitHub actions working on Windows again.

src/main/java/org/openjdk/jextract/clang/TranslationUnit.java line 96:

> 94:                 else {
> 95:                    start.set((ValueLayout.OfLong) C_LONG, LENGTH_OFFSET, (long) inMemoryFiles[i].contents.length());
> 96:                 }

There is some history here, but looking at this again, I think it would be better to use the setters that jextract generates here.


CXUnsavedFile.Filename(start, arena.allocateFrom(inMemoryFiles[i].file));
CXUnsavedFile.Contents(start, arena.allocateFrom(inMemoryFiles[i].contents));
CXUnsavedFile.Length(start, inMemoryFiles[i].contents.length());

src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java line 111:

> 109:         }
> 110:     }
> 111: 

I think you can just cast here
Suggestion:

    public static final ValueLayout C_LONG = (ValueLayout) Linker.nativeLinker().canonicalLayouts().get("long");

-------------

PR Review: https://git.openjdk.org/jextract/pull/289#pullrequestreview-3239416895
PR Review Comment: https://git.openjdk.org/jextract/pull/289#discussion_r2359484229
PR Review Comment: https://git.openjdk.org/jextract/pull/289#discussion_r2359037109

From jvernee at openjdk.org  Thu Sep 18 15:22:24 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 18 Sep 2025 15:22:24 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v4]
In-Reply-To: <uHUYaeVmb7ets9p40EXpAFayZwSEhWkkTteWNfxSaxI=.916381ac-1f01-4ddb-bba5-5bc0679f786a@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <-N5iaFrhbqxN7PkTvDkc58gyHk0AVKuRuEsmieslH1c=.c755adce-4585-4cff-a1f6-b13e48cfa4cf@github.com>
 <uHUYaeVmb7ets9p40EXpAFayZwSEhWkkTteWNfxSaxI=.916381ac-1f01-4ddb-bba5-5bc0679f786a@github.com>
Message-ID: <u8cLujsBllBa_ZR6RRAuIpixrH3a0KMAw8ey6Ye-4oo=.92d24b22-0965-49d7-90c1-554e3903a47f@github.com>

On Thu, 18 Sep 2025 14:03:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   7904079: Fix setting up length parameter for CXUnsavedFiles Struct
>
> src/main/java/org/openjdk/jextract/clang/TranslationUnit.java line 96:
> 
>> 94:                 else {
>> 95:                    start.set((ValueLayout.OfLong) C_LONG, LENGTH_OFFSET, (long) inMemoryFiles[i].contents.length());
>> 96:                 }
> 
> There is some history here, but looking at this again, I think it would be better to use the setters that jextract generates here.
> 
> 
> CXUnsavedFile.Filename(start, arena.allocateFrom(inMemoryFiles[i].file));
> CXUnsavedFile.Contents(start, arena.allocateFrom(inMemoryFiles[i].contents));
> CXUnsavedFile.Length(start, inMemoryFiles[i].contents.length());

If you make this change, please also remove the `*_OFFSET` fields, which are no longer needed.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/289#discussion_r2359839978

From varadam at openjdk.org  Fri Sep 19 14:06:16 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 19 Sep 2025 14:06:16 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v5]
In-Reply-To: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
Message-ID: <zs0g2Gu69aqHpE6wNNV5PU945xITklXVk_HH9LeLrNg=.2fac0408-2d8e-47d8-a10c-980d53338a0d@github.com>

> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
> 
> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  7904079: Fix setting up length parameter for CXUnsavedFiles Struct

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/289/files
  - new: https://git.openjdk.org/jextract/pull/289/files/812861a0..6043e0dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=04
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=03-04

  Stats: 52 lines in 3 files changed: 17 ins; 19 del; 16 mod
  Patch: https://git.openjdk.org/jextract/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/289/head:pull/289

PR: https://git.openjdk.org/jextract/pull/289

From varadam at openjdk.org  Fri Sep 19 14:06:20 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 19 Sep 2025 14:06:20 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v4]
In-Reply-To: <-N5iaFrhbqxN7PkTvDkc58gyHk0AVKuRuEsmieslH1c=.c755adce-4585-4cff-a1f6-b13e48cfa4cf@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <-N5iaFrhbqxN7PkTvDkc58gyHk0AVKuRuEsmieslH1c=.c755adce-4585-4cff-a1f6-b13e48cfa4cf@github.com>
Message-ID: <UWiLfRUCLXo6X4czbe_935GYkZpgCfct8vYrGCi4Agw=.c2391745-1b94-4838-b985-e1f55da6d296@github.com>

On Thu, 18 Sep 2025 12:17:48 GMT, Varada M <varadam at openjdk.org> wrote:

>> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
>> 
>> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7904079: Fix setting up length parameter for CXUnsavedFiles Struct

I?ve incorporated the suggested code changes, thank you for pointing these out. Build is successful from my end. I haven't tested on windows yet. Will update the status of windows soon.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/289#issuecomment-3312330861

From jvernee at openjdk.org  Fri Sep 19 14:55:34 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 19 Sep 2025 14:55:34 GMT
Subject: RFR: Fix GitHub actions
Message-ID: <nZvDMydqn89-SO7KY2Xqs3g-ZfZAjxoNVpgksBAOG7k=.ffb04d72-b240-4da4-a167-f7c1e93cacfe@github.com>

Currently we use JDK 23 as both the JDK on which to run Gradle (sourced from oracle.com), and the JDK with which to build jextract (sourced from jdk.java.net).

However, neither of these sources support JDK 23 any more.

This PR proposes to change the build JDK to 25. Since the version of Gradle that we use doesn't support 25, we use 21 for running Gradle. JDK 21 is sourced from oracle.com (it is LTS there), and 25 is sourced from jdk.java.net. i.e. the source of either is not changed.

Finally, the current actions are configured to use ubuntu-20.04, since we have a binary available for that system from the llvm-project releases page on github. However, runners with that version of ubuntu seem to be in short supply, and a job I tried to run took more than 24 hours to be picked (I ended up just cancelling it). I've switched the script to use ubuntu-latest, which seems to work fine with the same binary, and is much more readily available as a runner.

See here a successful run: https://github.com/JornVernee/jextract/actions/runs/17861448305

-------------

Commit messages:
 - Try running on ubuntu-latest
 - Change Java versions

Changes: https://git.openjdk.org/jextract/pull/290/files
  Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=290&range=00
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jextract/pull/290.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/290/head:pull/290

PR: https://git.openjdk.org/jextract/pull/290

From jvernee at openjdk.org  Fri Sep 19 15:09:52 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 19 Sep 2025 15:09:52 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v5]
In-Reply-To: <zs0g2Gu69aqHpE6wNNV5PU945xITklXVk_HH9LeLrNg=.2fac0408-2d8e-47d8-a10c-980d53338a0d@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <zs0g2Gu69aqHpE6wNNV5PU945xITklXVk_HH9LeLrNg=.2fac0408-2d8e-47d8-a10c-980d53338a0d@github.com>
Message-ID: <vLlNG_FvblhE1J45hmguATkGYqZURIOud8CKtM23tmg=.8e3ff5bc-4c04-49ec-9b4a-c5b57c28c149@github.com>

On Fri, 19 Sep 2025 14:06:16 GMT, Varada M <varadam at openjdk.org> wrote:

>> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
>> 
>> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7904079: Fix setting up length parameter for CXUnsavedFiles Struct

The latest version passes all tests on my Windows machine.

Could you please update the README at https://github.com/openjdk/jextract/tree/master/updateclang to reflect the changes that were needed to `CXUnsavedFile`? You can include the patch that I sent in that file.

Other than that, this looks ready to me.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/289#issuecomment-3312571016

From mcimadamore at openjdk.org  Fri Sep 19 16:10:38 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 Sep 2025 16:10:38 GMT
Subject: RFR: Fix GitHub actions
In-Reply-To: <nZvDMydqn89-SO7KY2Xqs3g-ZfZAjxoNVpgksBAOG7k=.ffb04d72-b240-4da4-a167-f7c1e93cacfe@github.com>
References: <nZvDMydqn89-SO7KY2Xqs3g-ZfZAjxoNVpgksBAOG7k=.ffb04d72-b240-4da4-a167-f7c1e93cacfe@github.com>
Message-ID: <OiOvrcUiPgBmD3p_pfyzKwS5blX4SkDxHgLoBdV5qwc=.d815d5ec-0386-42bc-94eb-c456e58c8871@github.com>

On Fri, 19 Sep 2025 14:49:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Currently we use JDK 23 as both the JDK on which to run Gradle (sourced from oracle.com), and the JDK with which to build jextract (sourced from jdk.java.net).
> 
> However, neither of these sources support JDK 23 any more.
> 
> This PR proposes to change the build JDK to 25. Since the version of Gradle that we use doesn't support 25, we use 21 for running Gradle. JDK 21 is sourced from oracle.com (it is LTS there), and 25 is sourced from jdk.java.net. i.e. the source of either is not changed.
> 
> Finally, the current actions are configured to use ubuntu-20.04, since we have a binary available for that system from the llvm-project releases page on github. However, runners with that version of ubuntu seem to be in short supply, and a job I tried to run took more than 24 hours to be picked (I ended up just cancelling it). I've switched the script to use ubuntu-latest, which seems to work fine with the same binary, and is much more readily available as a runner.
> 
> See here a successful run: https://github.com/JornVernee/jextract/actions/runs/17861448305

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jextract/pull/290#pullrequestreview-3245680398

From jvernee at openjdk.org  Fri Sep 19 16:27:52 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 19 Sep 2025 16:27:52 GMT
Subject: Integrated: Fix GitHub actions
In-Reply-To: <nZvDMydqn89-SO7KY2Xqs3g-ZfZAjxoNVpgksBAOG7k=.ffb04d72-b240-4da4-a167-f7c1e93cacfe@github.com>
References: <nZvDMydqn89-SO7KY2Xqs3g-ZfZAjxoNVpgksBAOG7k=.ffb04d72-b240-4da4-a167-f7c1e93cacfe@github.com>
Message-ID: <OJA2HbWx4MZonXabMm3gETEWz0LoIJV0AqNApAby9VY=.281a0531-6f80-45de-bb0d-e47314f88eef@github.com>

On Fri, 19 Sep 2025 14:49:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Currently we use JDK 23 as both the JDK on which to run Gradle (sourced from oracle.com), and the JDK with which to build jextract (sourced from jdk.java.net).
> 
> However, neither of these sources support JDK 23 any more.
> 
> This PR proposes to change the build JDK to 25. Since the version of Gradle that we use doesn't support 25, we use 21 for running Gradle. JDK 21 is sourced from oracle.com (it is LTS there), and 25 is sourced from jdk.java.net. i.e. the source of either is not changed.
> 
> Finally, the current actions are configured to use ubuntu-20.04, since we have a binary available for that system from the llvm-project releases page on github. However, runners with that version of ubuntu seem to be in short supply, and a job I tried to run took more than 24 hours to be picked (I ended up just cancelling it). I've switched the script to use ubuntu-latest, which seems to work fine with the same binary, and is much more readily available as a runner.
> 
> See here a successful run: https://github.com/JornVernee/jextract/actions/runs/17861448305

This pull request has now been integrated.

Changeset: 5991e8f7
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/5991e8f776b3644522844425a33cfd077bb958b0
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

Fix GitHub actions

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/290

From varadam at openjdk.org  Mon Sep 22 12:33:35 2025
From: varadam at openjdk.org (Varada M)
Date: Mon, 22 Sep 2025 12:33:35 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v6]
In-Reply-To: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
Message-ID: <LWKSjbYxBfXFoF5tbDX6eH3pu-rpe1uMyjbXU3JSErk=.6f1e4463-2887-453b-ac02-687b52ded645@github.com>

> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
> 
> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  7904079: Fix setting up length parameter for CXUnsavedFiles Struct

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/289/files
  - new: https://git.openjdk.org/jextract/pull/289/files/6043e0dd..550b0303

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=05
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=04-05

  Stats: 80 lines in 1 file changed: 79 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jextract/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/289/head:pull/289

PR: https://git.openjdk.org/jextract/pull/289

From varadam at openjdk.org  Mon Sep 22 12:41:56 2025
From: varadam at openjdk.org (Varada M)
Date: Mon, 22 Sep 2025 12:41:56 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v7]
In-Reply-To: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
Message-ID: <i4rYyytdIGg4EQAL8qt6WWDEXjP8H6wHdBqCYtQ9-Oc=.b4394e1b-ca14-4edf-8089-0b882d7c225f@github.com>

> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
> 
> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  7904079: Fix setting up length parameter for CXUnsavedFiles Struct

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/289/files
  - new: https://git.openjdk.org/jextract/pull/289/files/550b0303..7d4d58a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=06
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=05-06

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jextract/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/289/head:pull/289

PR: https://git.openjdk.org/jextract/pull/289

From varadam at openjdk.org  Mon Sep 22 12:46:03 2025
From: varadam at openjdk.org (Varada M)
Date: Mon, 22 Sep 2025 12:46:03 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v8]
In-Reply-To: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
Message-ID: <wjEpuxQHVfp1XY7tjR2VJWzifqBFP9tPKK6FTaluCsQ=.e05a04bc-9a3c-4519-90ad-4bd801a5b64f@github.com>

> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
> 
> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  7904079: Fix setting up length parameter for CXUnsavedFiles Struct

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/289/files
  - new: https://git.openjdk.org/jextract/pull/289/files/7d4d58a4..218a82de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=07
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/289.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/289/head:pull/289

PR: https://git.openjdk.org/jextract/pull/289

From varadam at openjdk.org  Mon Sep 22 12:46:04 2025
From: varadam at openjdk.org (Varada M)
Date: Mon, 22 Sep 2025 12:46:04 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v7]
In-Reply-To: <i4rYyytdIGg4EQAL8qt6WWDEXjP8H6wHdBqCYtQ9-Oc=.b4394e1b-ca14-4edf-8089-0b882d7c225f@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <i4rYyytdIGg4EQAL8qt6WWDEXjP8H6wHdBqCYtQ9-Oc=.b4394e1b-ca14-4edf-8089-0b882d7c225f@github.com>
Message-ID: <0DUxd4B2HUP74sEsh9TxzORb9ve2AJ1vywd5-4adAR0=.6b950854-2c6e-45f0-822b-40f1b09c77cd@github.com>

On Mon, 22 Sep 2025 12:41:56 GMT, Varada M <varadam at openjdk.org> wrote:

>> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
>> 
>> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7904079: Fix setting up length parameter for CXUnsavedFiles Struct

Thank you Jorn for testing on Windows. Updated the readme as well

-------------

PR Comment: https://git.openjdk.org/jextract/pull/289#issuecomment-3318778883

From jvernee at openjdk.org  Mon Sep 22 15:53:01 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 22 Sep 2025 15:53:01 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v8]
In-Reply-To: <wjEpuxQHVfp1XY7tjR2VJWzifqBFP9tPKK6FTaluCsQ=.e05a04bc-9a3c-4519-90ad-4bd801a5b64f@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <wjEpuxQHVfp1XY7tjR2VJWzifqBFP9tPKK6FTaluCsQ=.e05a04bc-9a3c-4519-90ad-4bd801a5b64f@github.com>
Message-ID: <1HF_Y_aMwVzxT7PL6R8JjsomCKJf-BdciDu8oxI7zyU=.76ab4d36-935b-4656-87e5-a21e9f8073c1@github.com>

On Mon, 22 Sep 2025 12:46:03 GMT, Varada M <varadam at openjdk.org> wrote:

>> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
>> 
>> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7904079: Fix setting up length parameter for CXUnsavedFiles Struct

Thanks for the updates! All tests pass here as well. This looks ready.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jextract/pull/289#pullrequestreview-3253679369

From varadam at openjdk.org  Tue Sep 23 06:46:17 2025
From: varadam at openjdk.org (Varada M)
Date: Tue, 23 Sep 2025 06:46:17 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v8]
In-Reply-To: <wjEpuxQHVfp1XY7tjR2VJWzifqBFP9tPKK6FTaluCsQ=.e05a04bc-9a3c-4519-90ad-4bd801a5b64f@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <wjEpuxQHVfp1XY7tjR2VJWzifqBFP9tPKK6FTaluCsQ=.e05a04bc-9a3c-4519-90ad-4bd801a5b64f@github.com>
Message-ID: <HbMAwFVZ5bfXRAKCMfmJofqtIVQbU-d_qj1VL8pH4X0=.63202772-d478-4059-b86f-71afcf8dd635@github.com>

On Mon, 22 Sep 2025 12:46:03 GMT, Varada M <varadam at openjdk.org> wrote:

>> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
>> 
>> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7904079: Fix setting up length parameter for CXUnsavedFiles Struct

Thank you,

-------------

PR Comment: https://git.openjdk.org/jextract/pull/289#issuecomment-3322631297

From duke at openjdk.org  Tue Sep 23 06:46:17 2025
From: duke at openjdk.org (duke)
Date: Tue, 23 Sep 2025 06:46:17 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v8]
In-Reply-To: <wjEpuxQHVfp1XY7tjR2VJWzifqBFP9tPKK6FTaluCsQ=.e05a04bc-9a3c-4519-90ad-4bd801a5b64f@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <wjEpuxQHVfp1XY7tjR2VJWzifqBFP9tPKK6FTaluCsQ=.e05a04bc-9a3c-4519-90ad-4bd801a5b64f@github.com>
Message-ID: <3oJbq_kWFbop_Kmy8LSrR1ZCM-sjRMicaQZddcFRENc=.0c9a5154-2fba-4253-84b2-7f819408bf90@github.com>

On Mon, 22 Sep 2025 12:46:03 GMT, Varada M <varadam at openjdk.org> wrote:

>> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
>> 
>> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7904079: Fix setting up length parameter for CXUnsavedFiles Struct

@varada1110 
Your change (at version 218a82de151f2481ec6ff0be9fb3dd69f256001d) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/289#issuecomment-3322632968

From mcimadamore at openjdk.org  Tue Sep 23 08:57:44 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 23 Sep 2025 08:57:44 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v8]
In-Reply-To: <wjEpuxQHVfp1XY7tjR2VJWzifqBFP9tPKK6FTaluCsQ=.e05a04bc-9a3c-4519-90ad-4bd801a5b64f@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <wjEpuxQHVfp1XY7tjR2VJWzifqBFP9tPKK6FTaluCsQ=.e05a04bc-9a3c-4519-90ad-4bd801a5b64f@github.com>
Message-ID: <enqIEBncK3V3YQ4VTn3b5lO1X8wz4-JZdfCxtmLbb8A=.074721e8-2809-4469-ba70-3a59ca79cc6b@github.com>

On Mon, 22 Sep 2025 12:46:03 GMT, Varada M <varadam at openjdk.org> wrote:

>> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
>> 
>> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7904079: Fix setting up length parameter for CXUnsavedFiles Struct

Thanks for fixing -- we should file an upstream issue against libclang to use `long long` in that struct, I suppose.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/289#issuecomment-3323016220

From varadam at openjdk.org  Tue Sep 23 08:57:46 2025
From: varadam at openjdk.org (Varada M)
Date: Tue, 23 Sep 2025 08:57:46 GMT
Subject: Integrated: 7904079: Fix setting up length parameter for
 CXUnsavedFiles Struct
In-Reply-To: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
Message-ID: <oQVsnZ9R0IxpF_9QkaqJATaWV9K9EdODo4uk865r_KQ=.54ff9a94-df5b-455b-97c7-b15868c7095e@github.com>

On Thu, 11 Sep 2025 06:50:59 GMT, Varada M <varadam at openjdk.org> wrote:

> CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. 
> 
> JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079)

This pull request has now been integrated.

Changeset: 63d0444c
Author:    Varada M <varadam at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/63d0444ca6333d7753a35eaff1d3a5febe614fbb
Stats:     120 lines in 4 files changed: 100 ins; 4 del; 16 mod

7904079: Fix setting up length parameter for CXUnsavedFiles Struct

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jextract/pull/289

From nbenalla at openjdk.org  Wed Sep 24 12:47:31 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 24 Sep 2025 12:47:31 GMT
Subject: RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles
 Struct [v8]
In-Reply-To: <HbMAwFVZ5bfXRAKCMfmJofqtIVQbU-d_qj1VL8pH4X0=.63202772-d478-4059-b86f-71afcf8dd635@github.com>
References: <N6xVPGNsRLo8UfhpsPCFhiXvKx3rNeuLGNkZf8yMLhk=.dd6fff82-d8d9-448b-8f92-a2ccb974093b@github.com>
 <wjEpuxQHVfp1XY7tjR2VJWzifqBFP9tPKK6FTaluCsQ=.e05a04bc-9a3c-4519-90ad-4bd801a5b64f@github.com>
 <HbMAwFVZ5bfXRAKCMfmJofqtIVQbU-d_qj1VL8pH4X0=.63202772-d478-4059-b86f-71afcf8dd635@github.com>
Message-ID: <6Va3zjPqFS0XaRDHWodKKohdaBiUv0ItIUSo5UBAcF4=.5d92a68e-f1dd-4628-baa2-e013dd300692@github.com>

On Tue, 23 Sep 2025 06:42:32 GMT, Varada M <varadam at openjdk.org> wrote:

>> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   7904079: Fix setting up length parameter for CXUnsavedFiles Struct
>
> Thank you,

I will handle filing the issue against libclang unless @varada1110 wants to be the one to do it.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/289#issuecomment-3328242114

From nbenalla at openjdk.org  Wed Sep 24 23:37:50 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 24 Sep 2025 23:37:50 GMT
Subject: RFR: 7904085: Changes needed for jdk25-based makefile build
Message-ID: <3UxGQjRc_goEJj7IM3JshQEym2gG8IEiVqrrQcFblr0=.e9909fdf-a1d0-492b-9e83-5235eea87c7f@github.com>

A simple version change, since JDK 25 was released.

-------------

Commit messages:
 - 8368566 changes

Changes: https://git.openjdk.org/jextract/pull/291/files
  Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=291&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904085
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/291.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/291/head:pull/291

PR: https://git.openjdk.org/jextract/pull/291

From jvernee at openjdk.org  Wed Sep 24 23:37:51 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 24 Sep 2025 23:37:51 GMT
Subject: RFR: 7904085: Changes needed for jdk25-based makefile build
In-Reply-To: <3UxGQjRc_goEJj7IM3JshQEym2gG8IEiVqrrQcFblr0=.e9909fdf-a1d0-492b-9e83-5235eea87c7f@github.com>
References: <3UxGQjRc_goEJj7IM3JshQEym2gG8IEiVqrrQcFblr0=.e9909fdf-a1d0-492b-9e83-5235eea87c7f@github.com>
Message-ID: <7GuuW8MN-euN3U9CSr8UIvZUywkzLxjZIU_n-mIhiZo=.7c8b848e-0ab0-4483-ab4e-e629b1eb9214@github.com>

On Wed, 24 Sep 2025 14:13:24 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> A simple version change, since JDK 25 was released.

I think you have the wrong bug ID

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jextract/pull/291#pullrequestreview-3263909832

From nbenalla at openjdk.org  Thu Sep 25 13:56:43 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 25 Sep 2025 13:56:43 GMT
Subject: RFR: 7904085: Changes needed for jdk25-based makefile build
In-Reply-To: <3UxGQjRc_goEJj7IM3JshQEym2gG8IEiVqrrQcFblr0=.e9909fdf-a1d0-492b-9e83-5235eea87c7f@github.com>
References: <3UxGQjRc_goEJj7IM3JshQEym2gG8IEiVqrrQcFblr0=.e9909fdf-a1d0-492b-9e83-5235eea87c7f@github.com>
Message-ID: <QZvIENN6Om4rWCVjIsMk-IcRTGKNl0LRnzpw9LLakY0=.2267e37d-bb1e-40a9-863c-f2050e5156eb@github.com>

On Wed, 24 Sep 2025 14:13:24 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> A simple version change, since JDK 25 was released.

Thanks Jorn for the review

-------------

PR Comment: https://git.openjdk.org/jextract/pull/291#issuecomment-3334232534

From duke at openjdk.org  Thu Sep 25 13:56:43 2025
From: duke at openjdk.org (duke)
Date: Thu, 25 Sep 2025 13:56:43 GMT
Subject: RFR: 7904085: Changes needed for jdk25-based makefile build
In-Reply-To: <3UxGQjRc_goEJj7IM3JshQEym2gG8IEiVqrrQcFblr0=.e9909fdf-a1d0-492b-9e83-5235eea87c7f@github.com>
References: <3UxGQjRc_goEJj7IM3JshQEym2gG8IEiVqrrQcFblr0=.e9909fdf-a1d0-492b-9e83-5235eea87c7f@github.com>
Message-ID: <X_C0Qc3GBoXDxxUNbIzHQ0skjMo-Yd3s8TDTt51x7Fc=.f9b24509-f381-44b9-b542-e996474fe32e@github.com>

On Wed, 24 Sep 2025 14:13:24 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> A simple version change, since JDK 25 was released.

@nizarbenalla 
Your change (at version 9a98460e5279b0571ba644955d539ef46cef7e82) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/291#issuecomment-3334237957

From nbenalla at openjdk.org  Thu Sep 25 14:41:47 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 25 Sep 2025 14:41:47 GMT
Subject: Integrated: 7904085: Changes needed for jdk25-based makefile build
In-Reply-To: <3UxGQjRc_goEJj7IM3JshQEym2gG8IEiVqrrQcFblr0=.e9909fdf-a1d0-492b-9e83-5235eea87c7f@github.com>
References: <3UxGQjRc_goEJj7IM3JshQEym2gG8IEiVqrrQcFblr0=.e9909fdf-a1d0-492b-9e83-5235eea87c7f@github.com>
Message-ID: <Lx_SASpslY5OOh8rHcMZGxT-mwer78que_7CMvv6oOA=.36fc4d91-e4f4-48ef-8303-9429db0eef4a@github.com>

On Wed, 24 Sep 2025 14:13:24 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> A simple version change, since JDK 25 was released.

This pull request has now been integrated.

Changeset: d41a3780
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/d41a378096a655ad95f0aa752eb8177db0f32775
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

7904085: Changes needed for jdk25-based makefile build

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jextract/pull/291