From nbenalla at openjdk.org  Fri Dec  6 23:08:00 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 6 Dec 2024 23:08:00 GMT
Subject: RFR: 7903878: jextract should derive struct field offsets from struct
 layouts
Message-ID: <V3-UU80Zr5vURUZ9BV9bQq1oohXEzbHyogazCC0omog=.9f2b0566-3baa-4051-b21e-857dd605dc97@github.com>

Please read the JBS issue for more details.

Currently jextract emits hardwired offsets, it would be better if the offsets could be computed dynamically from the struct layouts.

Passes all tests, unsure if this patch requires new tests.
Note: I used `fieldElementPaths(field.name())))` instead of the `javaName` to deal with nested structs.


It seems like GitHub actions are broken for Ubuntu? will look into this next week if necessary.

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

Commit messages:
 - jextract should derive struct field offsets from struct layouts

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

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

From a.trapletti at ustermetrics.com  Sun Dec  8 15:38:27 2024
From: a.trapletti at ustermetrics.com (Adrian Trapletti)
Date: Sun, 8 Dec 2024 16:38:27 +0100
Subject: Error with const variables
Message-ID: <CAGHZknEGZBugGhJH6gCMGT5v8CDd75bBaxXc+3b5eFayc6emzQ@mail.gmail.com>

Hi,

I run jextract on
https://github.com/ERGO-Code/HiGHS/blob/master/src/interfaces/highs_c_api.h
.

If I use the Java bindings to access the const variables I get
"java.lang.UnsatisfiedLinkError: unresolved symbol".

For example
...
long sense = kHighsObjSenseMinimize();
...

results in

java.lang.UnsatisfiedLinkError: unresolved symbol: kHighsObjSenseMinimize
at
com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.lambda$findOrThrow$0(highs_c_api_h.java:44)
at java.base/java.util.Optional.orElseThrow(Optional.java:403)
at
com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.findOrThrow(highs_c_api_h.java:44)
at
com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h$kHighsObjSenseMinimize$constants.<clinit>(highs_c_api_h.java:804)
at
com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.kHighsObjSenseMinimize(highs_c_api_h.java:834)
at
com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.BindingsTest.solveLinearProgramReturnsExpectedSolution(BindingsTest.java:32)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)

(https://github.com/atraplet/highs4j and run the unit tests)

What do I miss here?

Thx and best regards,
Adrian

*Dr. Adrian Trapletti*
CEO

*Uster Metrics GmbH  *|  Steinstrasse 9b, 8610 Uster, Switzerland
P +41 32 512 83 63  |  M +41 79 103 71 31
a.trapletti at ustermetrics.com  |  www.ustermetrics.com


This email message including any attachments is confidential and may be
privileged. It is intended solely for the use of the individual or entity
named on this message. It is provided for informational purposes only and
does not constitute an offer or invitation to subscribe for or purchase any
services or products. Any form of disclosure, copying, modification or
distribution is unauthorized. If you are not the intended recipient, you
are requested to please notify the sender immediately and delete the
message including any attachments from your computer system network. Email
transmission cannot be guaranteed to be secure or error free as information
could be modified. We therefore do not accept responsibility or liability
as to the completeness or accuracy of the information contained in this
message or any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20241208/2ac12e1d/attachment-0001.htm>

From mcimadamore at openjdk.org  Mon Dec  9 11:55:53 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Dec 2024 11:55:53 GMT
Subject: RFR: 7903878: jextract should derive struct field offsets from
 struct layouts
In-Reply-To: <V3-UU80Zr5vURUZ9BV9bQq1oohXEzbHyogazCC0omog=.9f2b0566-3baa-4051-b21e-857dd605dc97@github.com>
References: <V3-UU80Zr5vURUZ9BV9bQq1oohXEzbHyogazCC0omog=.9f2b0566-3baa-4051-b21e-857dd605dc97@github.com>
Message-ID: <O4frEG5zItGQyzKIO7LGBhZzmpU4RClRiPCBgeKnI44=.8d3cb1ea-c558-49e5-ba88-d2661f76163f@github.com>

On Fri, 6 Dec 2024 23:03:47 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please read the JBS issue for more details.
> 
> Currently jextract emits hardwired offsets, it would be better if the offsets could be computed dynamically from the struct layouts.
> 
> Passes all tests, unsure if this patch requires new tests.
> Note: I used `fieldElementPaths(field.name())))` instead of the `javaName` to deal with nested structs.
> 
> 
> It seems like GitHub actions are broken for Ubuntu? will look into this next week if necessary.

Looks good. In principle we could save the construction of `fieldElementPaths`, as we use that both in the offset and in the layout accessor (e.g. `emitOffsetFieldDecl` and `emitLayoutFieldDecl`) but I'm not sure how much that matters in practice, as I'd expect most layout paths to be a simple call to `groupElement(String)`.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jextract/pull/262#pullrequestreview-2488573097

From maurizio.cimadamore at oracle.com  Mon Dec  9 12:07:35 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 9 Dec 2024 12:07:35 +0000
Subject: Error with const variables
In-Reply-To: <CAGHZknEGZBugGhJH6gCMGT5v8CDd75bBaxXc+3b5eFayc6emzQ@mail.gmail.com>
References: <CAGHZknEGZBugGhJH6gCMGT5v8CDd75bBaxXc+3b5eFayc6emzQ@mail.gmail.com>
Message-ID: <b88f30ee-d6d1-4ad9-90a8-3e3bc2c2cab3@oracle.com>

Hi,
what OS/platform are you on?

I tried a small example on my Linux/x64:

|// foo.c const int x = 4; |

Then compiled to a shared library:

|gcc -shared -o foo.so |

Then, from jshell:

|jshell> import java.lang.foreign.*; jshell> SymbolLookup lookup = 
SymbolLookup.libraryLookup("./foo.so", Arena.global()); lookup ==> 
java.lang.foreign.SymbolLookup$$Lambda/0x00007f8d6705ac18 at 4459eb14 
jshell> lookup.findOrThrow("x"); $3 ==> MemorySegment{ address: 
0x7f8dc403c000, byteSize: 0 } |

So, the symbol seems to be there, which is also confirmed by |objdump|:

|foo.so: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: 0000000000000000 
w D *UND* 0000000000000000 __cxa_finalize 0000000000000000 w D *UND* 
0000000000000000 _ITM_registerTMCloneTable 0000000000000000 w D *UND* 
0000000000000000 _ITM_deregisterTMCloneTable 0000000000000000 w D *UND* 
0000000000000000 __gmon_start__ 0000000000002000 g DO .rodata 
0000000000000004 x |

(see last line)

I?d suggest to maybe check that (a) the shared library you are using 
(.so or .dll) does contain the constant variable symbols we?re trying to 
lookup and (b) that jextract is using a correct symbol lookup (e.g. one 
that points to your library). For (b) you might want to refer this for 
further guidance:

https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#library-loading

Cheers
Maurizio

On 08/12/2024 15:38, Adrian Trapletti wrote:

> Hi,
>
> I run jextract on 
> https://github.com/ERGO-Code/HiGHS/blob/master/src/interfaces/highs_c_api.h. 
>
>
> If I use the Java bindings to access the const variables I get 
> "java.lang.UnsatisfiedLinkError: unresolved symbol".
>
> For example
> ...
> long sense = kHighsObjSenseMinimize();
> ...
>
> results in
>
> java.lang.UnsatisfiedLinkError: unresolved symbol: kHighsObjSenseMinimize
> at 
> com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.lambda$findOrThrow$0(highs_c_api_h.java:44)
> at java.base/java.util.Optional.orElseThrow(Optional.java:403)
> at 
> com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.findOrThrow(highs_c_api_h.java:44)
> at 
> com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h$kHighsObjSenseMinimize$constants.<clinit>(highs_c_api_h.java:804)
> at 
> com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.kHighsObjSenseMinimize(highs_c_api_h.java:834)
> at 
> com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.BindingsTest.solveLinearProgramReturnsExpectedSolution(BindingsTest.java:32)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>
> (https://github.com/atraplet/highs4j and run the unit tests)
>
> What do I miss here?
>
> Thx and best regards,
> Adrian
>
> *Dr. Adrian Trapletti*
> CEO
>
> *Uster Metrics GmbH *| ?Steinstrasse 9b, 8610 Uster, Switzerland
> P +41 32 512 83 63 ?| M +41 79 103 71 31
> a.trapletti at ustermetrics.com | www.ustermetrics.com 
> <http://www.ustermetrics.com>
>
>
> This email message including any attachments is confidential and may 
> be privileged. It is intended solely for the use of the individual or 
> entity named on this message. It is provided for informational 
> purposes only and does not constitute an offer or invitation to 
> subscribe for or purchase any services or products. Any form of 
> disclosure, copying, modification or distribution is unauthorized. If 
> you are not the intended recipient, you are requested to please notify 
> the sender immediately and delete the message including any 
> attachments from your computer system network. Email transmission 
> cannot be guaranteed to be secure or error free as information could 
> be modified. We therefore do not accept responsibility or liability as 
> to the completeness or accuracy of the information contained in this 
> message or any attachments.
>
>
>
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20241209/3ae4fb29/attachment-0001.htm>

From a.trapletti at ustermetrics.com  Mon Dec  9 20:34:24 2024
From: a.trapletti at ustermetrics.com (Adrian Trapletti)
Date: Mon, 9 Dec 2024 21:34:24 +0100
Subject: Error with const variables
In-Reply-To: <b88f30ee-d6d1-4ad9-90a8-3e3bc2c2cab3@oracle.com>
References: <CAGHZknEGZBugGhJH6gCMGT5v8CDd75bBaxXc+3b5eFayc6emzQ@mail.gmail.com>
 <b88f30ee-d6d1-4ad9-90a8-3e3bc2c2cab3@oracle.com>
Message-ID: <CAGHZknHxS0yr=jR=OfUFYNW+AViNE4Q8-0OSPuNbAb-A4ZpQcA@mail.gmail.com>

Hi Maurizio

Thx for the help.

What I found out is that the issue is not jextract or the platform. It's C
vs C++ default external linkage vs default internal linkage for const
variable declarations (If you rename foo.c to foo.cpp, then the symbol
table does not contain x due to internal linkage. Only if it's declared as
"extern const int x = 4;" there is external linkage in C++). In my project
the header file is imported into a cpp file.

Best,
Adrian

*Dr. Adrian Trapletti*
CEO

*Uster Metrics GmbH  *|  Steinstrasse 9b, 8610 Uster, Switzerland
P +41 32 512 83 63  |  M +41 79 103 71 31
a.trapletti at ustermetrics.com  |  www.ustermetrics.com


This email message including any attachments is confidential and may be
privileged. It is intended solely for the use of the individual or entity
named on this message. It is provided for informational purposes only and
does not constitute an offer or invitation to subscribe for or purchase any
services or products. Any form of disclosure, copying, modification or
distribution is unauthorized. If you are not the intended recipient, you
are requested to please notify the sender immediately and delete the
message including any attachments from your computer system network. Email
transmission cannot be guaranteed to be secure or error free as information
could be modified. We therefore do not accept responsibility or liability
as to the completeness or accuracy of the information contained in this
message or any attachments.





On Mon, Dec 9, 2024 at 1:07?PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi,
> what OS/platform are you on?
>
> I tried a small example on my Linux/x64:
>
> // foo.cconst int x = 4;
>
> Then compiled to a shared library:
>
> gcc -shared -o foo.so
>
> Then, from jshell:
>
> jshell> import java.lang.foreign.*;
>
> jshell> SymbolLookup lookup = SymbolLookup.libraryLookup("./foo.so", Arena.global());
> lookup ==> java.lang.foreign.SymbolLookup$$Lambda/0x00007f8d6705ac18 at 4459eb14
>
> jshell> lookup.findOrThrow("x");
> $3 ==> MemorySegment{ address: 0x7f8dc403c000, byteSize: 0 }
>
> So, the symbol seems to be there, which is also confirmed by objdump:
>
> foo.so:     file format elf64-x86-64
>
> DYNAMIC SYMBOL TABLE:
> 0000000000000000  w   D  *UND*    0000000000000000 __cxa_finalize
> 0000000000000000  w   D  *UND*    0000000000000000 _ITM_registerTMCloneTable
> 0000000000000000  w   D  *UND*    0000000000000000 _ITM_deregisterTMCloneTable
> 0000000000000000  w   D  *UND*    0000000000000000 __gmon_start__
> 0000000000002000 g    DO .rodata    0000000000000004 x
>
> (see last line)
>
> I?d suggest to maybe check that (a) the shared library you are using (.so
> or .dll) does contain the constant variable symbols we?re trying to lookup
> and (b) that jextract is using a correct symbol lookup (e.g. one that
> points to your library). For (b) you might want to refer this for further
> guidance:
>
>
> https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#library-loading
>
> Cheers
> Maurizio
>
> On 08/12/2024 15:38, Adrian Trapletti wrote:
>
> Hi,
>
> I run jextract on
> https://github.com/ERGO-Code/HiGHS/blob/master/src/interfaces/highs_c_api.h
> .
>
> If I use the Java bindings to access the const variables I get
> "java.lang.UnsatisfiedLinkError: unresolved symbol".
>
> For example
> ...
> long sense = kHighsObjSenseMinimize();
> ...
>
> results in
>
> java.lang.UnsatisfiedLinkError: unresolved symbol: kHighsObjSenseMinimize
> at
> com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.lambda$findOrThrow$0(highs_c_api_h.java:44)
> at java.base/java.util.Optional.orElseThrow(Optional.java:403)
> at
> com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.findOrThrow(highs_c_api_h.java:44)
> at
> com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h$kHighsObjSenseMinimize$constants.<clinit>(highs_c_api_h.java:804)
> at
> com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.kHighsObjSenseMinimize(highs_c_api_h.java:834)
> at
> com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.BindingsTest.solveLinearProgramReturnsExpectedSolution(BindingsTest.java:32)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>
> (https://github.com/atraplet/highs4j and run the unit tests)
>
> What do I miss here?
>
> Thx and best regards,
> Adrian
>
> *Dr. Adrian Trapletti*
> CEO
>
> *Uster Metrics GmbH  *|  Steinstrasse 9b, 8610 Uster, Switzerland
> P +41 32 512 83 63  |  M +41 79 103 71 31
> a.trapletti at ustermetrics.com  |  www.ustermetrics.com
>
>
> This email message including any attachments is confidential and may be
> privileged. It is intended solely for the use of the individual or entity
> named on this message. It is provided for informational purposes only and
> does not constitute an offer or invitation to subscribe for or purchase
> any services or products. Any form of disclosure, copying, modification
> or distribution is unauthorized. If you are not the intended recipient,
> you are requested to please notify the sender immediately and delete the
> message including any attachments from your computer system network. Email
> transmission cannot be guaranteed to be secure or error free as information
> could be modified. We therefore do not accept responsibility or liability
> as to the completeness or accuracy of the information contained in this
> message or any attachments.
>
>
>
> ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20241209/7bffe61b/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Mon Dec  9 22:16:55 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 9 Dec 2024 22:16:55 +0000
Subject: Error with const variables
In-Reply-To: <CAGHZknHxS0yr=jR=OfUFYNW+AViNE4Q8-0OSPuNbAb-A4ZpQcA@mail.gmail.com>
References: <CAGHZknEGZBugGhJH6gCMGT5v8CDd75bBaxXc+3b5eFayc6emzQ@mail.gmail.com>
 <b88f30ee-d6d1-4ad9-90a8-3e3bc2c2cab3@oracle.com>
 <CAGHZknHxS0yr=jR=OfUFYNW+AViNE4Q8-0OSPuNbAb-A4ZpQcA@mail.gmail.com>
Message-ID: <b53087e7-0347-45e0-be2d-91ed5c5714b2@oracle.com>

Hi,
Jorn and I were looking into this one earlier today, and discovered a 
similar thing.

Now, with jextract it could be possible, in principle, to treat ?const 
int x = 4? as a constant, and generate a ?constant getter? instead of 
trying to get a segment that points at the storage holding the global 
variable (which is how jextract would normally translate global variables).

However, we got a bit stuck with string constant - e.g. if you have 
something like this:

|char* const z = "Hello"; |

jextract would end up generating something like this:

|/** * {@snippet lang=c : * char *const z Hello * } */ public static 
MemorySegment z() { class Holder { static final MemorySegment z = 
foo_h.LIBRARY_ARENA.allocateFrom("Hello"); } return Holder.z; } |

This is a bit unfortunate, because we will try to allocate a string, 
even though a region of memory with the string in it might be available 
if the global variable is made available by the shared library.

One thing we discussed was to, maybe tweak the accessor, so that if the 
global variable lookup fails, we return a newly allocated string 
constant instead. But it seems a bit convoluted.

In the meantime, there is a workaround you could do:

  * you could define a new header file which includes the original one,
    and which defines all the constants you want are defined using
    pre-processor macros |#define|
  * then you run jextract on both the new header file
  * you tell jextract not to generate bindings for the constant
    /variables/ - this can be done using jextract?s filtering options [1]

It?s a bit roundabout, but it should give you want you want (I hope!). 
In the meantime, we?ll keep thinking if there?s anything better we can 
do to deal with this use case. Thanks for bringing it to our attention!

Cheers
Maurizio

[1] - https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#filtering

On 09/12/2024 20:34, Adrian Trapletti wrote:

> Hi Maurizio
>
> Thx for the help.
>
> What I found out is that the issue is not jextract or the platform. 
> It's C vs C++ default external linkage vs default internal linkage for 
> const variable?declarations (If you rename foo.c to foo.cpp, then the 
> symbol table does not contain x due to internal linkage. Only if it's 
> declared as "extern const int x = 4;" there is external linkage in 
> C++). In my project the header file is imported?into a cpp file.
>
> Best,
> Adrian
>
> *Dr. Adrian Trapletti*
> CEO
>
> *Uster Metrics GmbH *| ?Steinstrasse 9b, 8610 Uster, Switzerland
> P +41 32 512 83 63 ?| M +41 79 103 71 31
> a.trapletti at ustermetrics.com | www.ustermetrics.com 
> <https://urldefense.com/v3/__http://www.ustermetrics.com__;!!ACWV5N9M2RV99hQ!IFLIy2aJmgLaooCbWq_vPOt96l0G24YRJbrtwUnJQe4Ae_AV9plEysCzPrfvPBU32c26Sd3kLMrNWzQrC5o6euY-b2WMF4wJ$>
>
>
> This email message including any attachments is confidential and may 
> be privileged. It is intended solely for the use of the individual or 
> entity named on this message. It is provided for informational 
> purposes only and does not constitute an offer or invitation to 
> subscribe for or purchase any services or products. Any form of 
> disclosure, copying, modification or distribution is unauthorized. If 
> you are not the intended recipient, you are requested to please notify 
> the sender immediately and delete the message including any 
> attachments from your computer system network. Email transmission 
> cannot be guaranteed to be secure or error free as information could 
> be modified. We therefore do not accept responsibility or liability as 
> to the completeness or accuracy of the information contained in this 
> message or any attachments.
>
>
>
>
>
> On Mon, Dec 9, 2024 at 1:07?PM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>
>     Hi,
>     what OS/platform are you on?
>
>     I tried a small example on my Linux/x64:
>
>     |// foo.c const int x = 4; |
>
>     Then compiled to a shared library:
>
>     |gcc -shared -o foo.so |
>
>     Then, from jshell:
>
>     |jshell> import java.lang.foreign.*; jshell> SymbolLookup lookup =
>     SymbolLookup.libraryLookup("./foo.so", Arena.global()); lookup ==>
>     java.lang.foreign.SymbolLookup$Lambda/0x00007f8d6705ac18 at 4459eb14
>     jshell> lookup.findOrThrow("x"); $3 ==> MemorySegment{ address:
>     0x7f8dc403c000, byteSize: 0 } |
>
>     So, the symbol seems to be there, which is also confirmed by
>     |objdump|:
>
>     |foo.so: file format elf64-x86-64 DYNAMIC SYMBOL TABLE:
>     0000000000000000 w D *UND* 0000000000000000 __cxa_finalize
>     0000000000000000 w D *UND* 0000000000000000
>     _ITM_registerTMCloneTable 0000000000000000 w D *UND*
>     0000000000000000 _ITM_deregisterTMCloneTable 0000000000000000 w D
>     *UND* 0000000000000000 __gmon_start__ 0000000000002000 g DO
>     .rodata 0000000000000004 x |
>
>     (see last line)
>
>     I?d suggest to maybe check that (a) the shared library you are
>     using (.so or .dll) does contain the constant variable symbols
>     we?re trying to lookup and (b) that jextract is using a correct
>     symbol lookup (e.g. one that points to your library). For (b) you
>     might want to refer this for further guidance:
>
>     https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#library-loading
>     <https://urldefense.com/v3/__https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md*library-loading__;Iw!!ACWV5N9M2RV99hQ!IFLIy2aJmgLaooCbWq_vPOt96l0G24YRJbrtwUnJQe4Ae_AV9plEysCzPrfvPBU32c26Sd3kLMrNWzQrC5o6euY-bwjt5prT$>
>
>     Cheers
>     Maurizio
>
>     On 08/12/2024 15:38, Adrian Trapletti wrote:
>
>>     Hi,
>>
>>     I run jextract on
>>     https://github.com/ERGO-Code/HiGHS/blob/master/src/interfaces/highs_c_api.h
>>     <https://urldefense.com/v3/__https://github.com/ERGO-Code/HiGHS/blob/master/src/interfaces/highs_c_api.h__;!!ACWV5N9M2RV99hQ!IFLIy2aJmgLaooCbWq_vPOt96l0G24YRJbrtwUnJQe4Ae_AV9plEysCzPrfvPBU32c26Sd3kLMrNWzQrC5o6euY-b4S629Bv$>.
>>
>>
>>     If I use the Java bindings to access the const variables I get
>>     "java.lang.UnsatisfiedLinkError: unresolved symbol".
>>
>>     For example
>>     ...
>>     long sense = kHighsObjSenseMinimize();
>>     ...
>>
>>     results in
>>
>>     java.lang.UnsatisfiedLinkError: unresolved symbol:
>>     kHighsObjSenseMinimize
>>     at
>>     com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.lambda$findOrThrow$0(highs_c_api_h.java:44)
>>     at java.base/java.util.Optional.orElseThrow(Optional.java:403)
>>     at
>>     com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.findOrThrow(highs_c_api_h.java:44)
>>     at
>>     com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h$kHighsObjSenseMinimize$constants.<clinit>(highs_c_api_h.java:804)
>>     at
>>     com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.kHighsObjSenseMinimize(highs_c_api_h.java:834)
>>     at
>>     com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.BindingsTest.solveLinearProgramReturnsExpectedSolution(BindingsTest.java:32)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>>
>>     (https://github.com/atraplet/highs4j
>>     <https://urldefense.com/v3/__https://github.com/atraplet/highs4j__;!!ACWV5N9M2RV99hQ!IFLIy2aJmgLaooCbWq_vPOt96l0G24YRJbrtwUnJQe4Ae_AV9plEysCzPrfvPBU32c26Sd3kLMrNWzQrC5o6euY-b-fAs9n_$>
>>     and run the unit tests)
>>
>>     What do I miss here?
>>
>>     Thx and best regards,
>>     Adrian
>>
>>     *Dr. Adrian Trapletti*
>>     CEO
>>
>>     *Uster Metrics GmbH *| ?Steinstrasse 9b, 8610 Uster, Switzerland
>>     P +41 32 512 83 63 ?| M +41 79 103 71 31
>>     a.trapletti at ustermetrics.com? | www.ustermetrics.com
>>     <https://urldefense.com/v3/__http://www.ustermetrics.com__;!!ACWV5N9M2RV99hQ!IFLIy2aJmgLaooCbWq_vPOt96l0G24YRJbrtwUnJQe4Ae_AV9plEysCzPrfvPBU32c26Sd3kLMrNWzQrC5o6euY-b2WMF4wJ$>
>>
>>
>>     This email message including any attachments is confidential and
>>     may be privileged. It is intended solely for the use of the
>>     individual or entity named on this message. It is provided for
>>     informational purposes only and does not constitute an offer or
>>     invitation to subscribe for or purchase any services or products.
>>     Any form of disclosure, copying, modification or distribution is
>>     unauthorized. If you are not the intended recipient, you are
>>     requested to please notify the sender immediately and delete the
>>     message including any attachments from your computer system
>>     network. Email transmission cannot be guaranteed to be secure or
>>     error free as information could be modified. We therefore do not
>>     accept responsibility or liability as to the completeness or
>>     accuracy of the information contained in this message or any
>>     attachments.
>>
>>
>>
>     ?
>
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20241209/793455cb/attachment-0001.htm>

From nbenalla at openjdk.org  Wed Dec 11 15:42:27 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 11 Dec 2024 15:42:27 GMT
Subject: RFR: 7903878: jextract should derive struct field offsets from
 struct layouts
In-Reply-To: <V3-UU80Zr5vURUZ9BV9bQq1oohXEzbHyogazCC0omog=.9f2b0566-3baa-4051-b21e-857dd605dc97@github.com>
References: <V3-UU80Zr5vURUZ9BV9bQq1oohXEzbHyogazCC0omog=.9f2b0566-3baa-4051-b21e-857dd605dc97@github.com>
Message-ID: <pMFTweQQKX-bUB4c7w-xLZtwoNGcr1GkmZaQ8YR3swk=.c880f652-4f1c-4c8e-82e6-0328788487de@github.com>

On Fri, 6 Dec 2024 23:03:47 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please read the JBS issue for more details.
> 
> Currently jextract emits hardwired offsets, it would be better if the offsets could be computed dynamically from the struct layouts.
> 
> Passes all tests, unsure if this patch requires new tests.
> Note: I used `fieldElementPaths(field.name())))` instead of the `javaName` to deal with nested structs.
> 
> 
> It seems like GitHub actions are broken for Ubuntu? will look into this next week if necessary.

On the same platforms, the offset are same the before/after the patch.

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

PR Comment: https://git.openjdk.org/jextract/pull/262#issuecomment-2536343329

From duke at openjdk.org  Wed Dec 11 15:42:27 2024
From: duke at openjdk.org (duke)
Date: Wed, 11 Dec 2024 15:42:27 GMT
Subject: RFR: 7903878: jextract should derive struct field offsets from
 struct layouts
In-Reply-To: <V3-UU80Zr5vURUZ9BV9bQq1oohXEzbHyogazCC0omog=.9f2b0566-3baa-4051-b21e-857dd605dc97@github.com>
References: <V3-UU80Zr5vURUZ9BV9bQq1oohXEzbHyogazCC0omog=.9f2b0566-3baa-4051-b21e-857dd605dc97@github.com>
Message-ID: <edi-czOLbOHdLSekQBcRDjVLb5e0FafVkW1UFFdLpBQ=.616b3b58-b429-4e0b-a85d-30cc3e42d15c@github.com>

On Fri, 6 Dec 2024 23:03:47 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please read the JBS issue for more details.
> 
> Currently jextract emits hardwired offsets, it would be better if the offsets could be computed dynamically from the struct layouts.
> 
> Passes all tests, unsure if this patch requires new tests.
> Note: I used `fieldElementPaths(field.name())))` instead of the `javaName` to deal with nested structs.
> 
> 
> It seems like GitHub actions are broken for Ubuntu? will look into this next week if necessary.

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

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

PR Comment: https://git.openjdk.org/jextract/pull/262#issuecomment-2536345625

From nbenalla at openjdk.org  Wed Dec 11 16:51:27 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 11 Dec 2024 16:51:27 GMT
Subject: Integrated: 7903878: jextract should derive struct field offsets from
 struct layouts
In-Reply-To: <V3-UU80Zr5vURUZ9BV9bQq1oohXEzbHyogazCC0omog=.9f2b0566-3baa-4051-b21e-857dd605dc97@github.com>
References: <V3-UU80Zr5vURUZ9BV9bQq1oohXEzbHyogazCC0omog=.9f2b0566-3baa-4051-b21e-857dd605dc97@github.com>
Message-ID: <XL54-ekwUdtAokZbuFI2aat7QAPZenqR92CUfsaaUNY=.a954a7e6-8f33-44fd-85ab-f9c06980334d@github.com>

On Fri, 6 Dec 2024 23:03:47 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please read the JBS issue for more details.
> 
> Currently jextract emits hardwired offsets, it would be better if the offsets could be computed dynamically from the struct layouts.
> 
> Passes all tests, unsure if this patch requires new tests.
> Note: I used `fieldElementPaths(field.name())))` instead of the `javaName` to deal with nested structs.
> 
> 
> It seems like GitHub actions are broken for Ubuntu? will look into this next week if necessary.

This pull request has now been integrated.

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

7903878: jextract should derive struct field offsets from struct layouts

Reviewed-by: mcimadamore

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

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

From jvernee at openjdk.org  Thu Dec 12 17:01:11 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Dec 2024 17:01:11 GMT
Subject: RFR: Touch up gradle build
Message-ID: <83EG5_SRcqVMtzQ8Xh5q2zn-nAmD6zVSILsXowvlHiA=.86f793ed-8820-4b1c-ac44-89b5991eccf8@github.com>

I'm setting up the jextract repo on a new machine, and ran into a couple of small build issues that this PR addresses:

1.) intellij will try to collect all tasks defined by the gradle build, but this is currently failing if you don't have the jacoco agent configured, since that's needed to 'configure' one of the test tasks. The fix I added is to only lazily register the test task for coverage instead.

2.) If you want to debug a jtreg test through Intellij, it's nice to be able to build the test image and native test libraries as a pre-run step. I've added a new task called `testDeps` which does both of these things, and can be easily referenced from a run configuration.

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

Commit messages:
 - Touch up build file

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

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

From jvernee at openjdk.org  Thu Dec 12 17:01:11 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Dec 2024 17:01:11 GMT
Subject: RFR: Touch up gradle build
In-Reply-To: <83EG5_SRcqVMtzQ8Xh5q2zn-nAmD6zVSILsXowvlHiA=.86f793ed-8820-4b1c-ac44-89b5991eccf8@github.com>
References: <83EG5_SRcqVMtzQ8Xh5q2zn-nAmD6zVSILsXowvlHiA=.86f793ed-8820-4b1c-ac44-89b5991eccf8@github.com>
Message-ID: <pfrKy-TtkqdtpClIi9hqpIR1QMkJbtNg65cuyUPzZSE=.b91059c3-c480-4010-99bc-95860e6a1b3b@github.com>

On Wed, 11 Dec 2024 18:26:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I'm setting up the jextract repo on a new machine, and ran into a couple of small build issues that this PR addresses:
> 
> 1.) intellij will try to collect all tasks defined by the gradle build, but this is currently failing if you don't have the jacoco agent configured, since that's needed to 'configure' one of the test tasks. The fix I added is to only lazily register the test task for coverage instead.
> 
> 2.) If you want to debug a jtreg test through Intellij, it's nice to be able to build the test image and native test libraries as a pre-run step. I've added a new task called `testDeps` which does both of these things, and can be easily referenced from a run configuration.

FWIW, I also took a look at the failing github actions. The issue is that both the toolchain JDK 22, and the gradle JDK 17, are no longer available. Bumping the versions is easy enough, but we also need to update the gradle version we use in that case. Will save that for another PR.

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

PR Comment: https://git.openjdk.org/jextract/pull/263#issuecomment-2539505574

From mcimadamore at openjdk.org  Fri Dec 13 09:58:50 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Dec 2024 09:58:50 GMT
Subject: RFR: Touch up gradle build
In-Reply-To: <83EG5_SRcqVMtzQ8Xh5q2zn-nAmD6zVSILsXowvlHiA=.86f793ed-8820-4b1c-ac44-89b5991eccf8@github.com>
References: <83EG5_SRcqVMtzQ8Xh5q2zn-nAmD6zVSILsXowvlHiA=.86f793ed-8820-4b1c-ac44-89b5991eccf8@github.com>
Message-ID: <EjXEOgYveHUhd8mAoSWrOwL2ve9JF56fpZDNCGucXzY=.3f8d62de-a5f8-4da8-912e-9d876505ae9c@github.com>

On Wed, 11 Dec 2024 18:26:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I'm setting up the jextract repo on a new machine, and ran into a couple of small build issues that this PR addresses:
> 
> 1.) intellij will try to collect all tasks defined by the gradle build, but this is currently failing if you don't have the jacoco agent configured, since that's needed to 'configure' one of the test tasks. The fix I added is to only lazily register the test task for coverage instead.
> 
> 2.) If you want to debug a jtreg test through Intellij, it's nice to be able to build the test image and native test libraries as a pre-run step. I've added a new task called `testDeps` which does both of these things, and can be easily referenced from a run configuration.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jextract/pull/263#pullrequestreview-2501882033

From jvernee at openjdk.org  Fri Dec 13 13:16:49 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Dec 2024 13:16:49 GMT
Subject: Integrated: Touch up gradle build
In-Reply-To: <83EG5_SRcqVMtzQ8Xh5q2zn-nAmD6zVSILsXowvlHiA=.86f793ed-8820-4b1c-ac44-89b5991eccf8@github.com>
References: <83EG5_SRcqVMtzQ8Xh5q2zn-nAmD6zVSILsXowvlHiA=.86f793ed-8820-4b1c-ac44-89b5991eccf8@github.com>
Message-ID: <RNHueRsuGv7aruPtk6d59Id9TxiWYpvAfd74tenkv6g=.6c769e4a-7f91-467e-9ea3-c9887862b545@github.com>

On Wed, 11 Dec 2024 18:26:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I'm setting up the jextract repo on a new machine, and ran into a couple of small build issues that this PR addresses:
> 
> 1.) intellij will try to collect all tasks defined by the gradle build, but this is currently failing if you don't have the jacoco agent configured, since that's needed to 'configure' one of the test tasks. The fix I added is to only lazily register the test task for coverage instead.
> 
> 2.) If you want to debug a jtreg test through Intellij, it's nice to be able to build the test image and native test libraries as a pre-run step. I've added a new task called `testDeps` which does both of these things, and can be easily referenced from a run configuration.

This pull request has now been integrated.

Changeset: e870893c
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/e870893cde2f8b7e6e318873c8f49e3ec46e7289
Stats:     19 lines in 1 file changed: 9 ins; 5 del; 5 mod

Touch up gradle build

Reviewed-by: mcimadamore

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

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

From jvernee at openjdk.org  Tue Dec 17 13:39:28 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 17 Dec 2024 13:39:28 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions
Message-ID: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>

Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.

There are 2 barriers to upgrading these JDK version to ones that are supported:
1. The current version of Gradle we are using doesn't run on newer Java versions
2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.

This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.

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

Commit messages:
 - remove --enable-preview in make build as well
 - add explicit javac exe suffix
 - Merge branch 'Stash' into UpdateGradle
 - work around  deprecation
 - drop --enable-preview flags
 - Update GHA java versions to 23
 - Update gradle to version 8.11.1

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

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

From jvernee at openjdk.org  Tue Dec 17 13:39:29 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 17 Dec 2024 13:39:29 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions
In-Reply-To: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
Message-ID: <TimWt-r7WqDOf9FvlEybkOux3HBKud4TCOzMt6nCO54=.132edf21-5b99-4322-a494-4c44c7ef7eb8@github.com>

On Tue, 17 Dec 2024 13:35:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
> 
> There are 2 barriers to upgrading these JDK version to ones that are supported:
> 1. The current version of Gradle we are using doesn't run on newer Java versions
> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
> 
> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.

build.gradle line 41:

> 39: def clang_version = clang_versions[0]
> 40: 
> 41: def buildDir = layout.buildDirectory.get()

`$buildDir` is deprecated in the latest version of Gradle. This is a workaround.

build.gradle line 64:

> 62:     options.release = 22
> 63:     options.fork = true
> 64:     options.forkOptions.executable = "${jdk22_home}/bin/javac${os_exe_suffix}"

This change also seemed to be needed for the build to work in GHA on Windows.

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

PR Review Comment: https://git.openjdk.org/jextract/pull/264#discussion_r1888531610
PR Review Comment: https://git.openjdk.org/jextract/pull/264#discussion_r1888530970

From nbenalla at openjdk.org  Tue Dec 17 16:40:22 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 17 Dec 2024 16:40:22 GMT
Subject: RFR: 7903917: Changes needed for jdk23-based makefile build
Message-ID: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>

Changes necessary to bump the supported version to JDK 23.
Passes tier 1.

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

Commit messages:
 - CODETOOLS-7903917

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

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

From nbenalla at openjdk.org  Tue Dec 17 18:44:02 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 17 Dec 2024 18:44:02 GMT
Subject: RFR: 7903735: Remove redundant method in generated code
Message-ID: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>

Was looking at older issues and saw an opportunity for a refractor.
I don't see a dependent PR feature for this repo but this is meant to be merged after https://github.com/openjdk/jextract/pull/265

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

Commit messages:
 - use newer method from JDK 23

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

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

From pminborg at openjdk.org  Wed Dec 18 08:15:51 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Dec 2024 08:15:51 GMT
Subject: RFR: 7903735: Remove redundant method in generated code
In-Reply-To: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
References: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
Message-ID: <8RVAYFpF4dWc5bq2or2Z8vOl43NhnxAWpCagqvy5yUg=.108c38a2-b6b5-40d7-a593-b0c6b0bfd6f9@github.com>

On Tue, 17 Dec 2024 18:39:19 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Was looking at older issues and saw an opportunity for a refractor.
> I don't see a dependent PR feature for this repo but this is meant to be merged after https://github.com/openjdk/jextract/pull/265

In the event of a symbol not being found, a `NoSuchElementException` will be thrown instead of an `UnsatisfiedLinkError` that used to be thrown. This means the generated code will behave a bit differently.

On the upside, there is no need for capturing a new lambda upon each lookup which would improve startup time.

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

PR Comment: https://git.openjdk.org/jextract/pull/266#issuecomment-2550633578

From jvernee at openjdk.org  Wed Dec 18 14:02:04 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Dec 2024 14:02:04 GMT
Subject: RFR: 7903735: Remove redundant method in generated code
In-Reply-To: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
References: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
Message-ID: <JO3HwBD3fjjOsumBwr9iQBg36OXWejiE-a-mex9TOdU=.a0331444-5ce0-4e03-9095-d34e717db89a@github.com>

On Tue, 17 Dec 2024 18:39:19 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Was looking at older issues and saw an opportunity for a refractor.
> I don't see a dependent PR feature for this repo but this is meant to be merged after https://github.com/openjdk/jextract/pull/265

I think this looks good. The important thing here is not the exception type, I think, but the fact that the error message contains the symbol, which is still the case with `findOrThrow`.

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

Marked as reviewed by jvernee (Committer).

PR Review: https://git.openjdk.org/jextract/pull/266#pullrequestreview-2511921283

From nbenalla at openjdk.org  Wed Dec 18 14:27:52 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Dec 2024 14:27:52 GMT
Subject: RFR: 7903735: Remove redundant method in generated code
In-Reply-To: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
References: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
Message-ID: <UB-qmGCP9CMPXiQSOKHnSMRX1zSPiNAznrb0Evjqivg=.d3e9dfac-05d3-4329-8171-2bc0c960eca5@github.com>

On Tue, 17 Dec 2024 18:39:19 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Was looking at older issues and saw an opportunity for a refractor.
> I don't see a dependent PR feature for this repo but this is meant to be merged after https://github.com/openjdk/jextract/pull/265

Yes, the [error message](https://github.com/openjdk/jdk/blob/8efc5585b74714df6cf8e66853cb63d223534455/src/java.base/share/classes/java/lang/foreign/SymbolLookup.java#L180) still contains the symbol.

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

PR Comment: https://git.openjdk.org/jextract/pull/266#issuecomment-2551455973

From jvernee at openjdk.org  Wed Dec 18 16:27:52 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Dec 2024 16:27:52 GMT
Subject: RFR: 7903917: Changes needed for jdk23-based makefile build
In-Reply-To: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>
References: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>
Message-ID: <o70p55erwRr8F3_rszbbEab460g9Xs8tR0CGSx4iE_I=.90980f60-e89e-41dc-8660-3894768d6cd7@github.com>

On Tue, 17 Dec 2024 16:35:00 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Changes necessary to bump the supported version to JDK 23.
> Passes tier 1.
> 
> Note: This PR will not be integrated before https://github.com/openjdk/jextract/pull/264 as the removal of `--enable-preview` is needed.

make/Build.gmk line 50:

> 48: 	$(MKDIR) -p $(BUILD_CLASSES_DIR)/org/openjdk/jextract/impl
> 49: 	$(FIXPATH) $(PANAMA_JAVA_HOME)/bin/javac \
> 50: 	    --release=23 \

I suppose once we drop `--enable-preview` the `--release flag` can also be dropped, and will just default to the version of the JDK we are building with. This is fine as the same JDK is used to create the jextract runtime image.

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

PR Review Comment: https://git.openjdk.org/jextract/pull/265#discussion_r1890516833

From nbenalla at openjdk.org  Wed Dec 18 17:43:27 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Dec 2024 17:43:27 GMT
Subject: RFR: 7903917: Changes needed for jdk23-based makefile build [v2]
In-Reply-To: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>
References: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>
Message-ID: <HWzztWTZQMBPsxMYQh5YtcDG45K3_50nAtNN6ltH-vQ=.b6573b0e-d175-4fd4-af50-9322f893e7a7@github.com>

> Changes necessary to bump the supported version to JDK 23.
> Passes tier 1.
> 
> Note: This PR will not be integrated before https://github.com/openjdk/jextract/pull/264 as the removal of `--enable-preview` is needed.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  remove --release flag

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

Changes:
  - all: https://git.openjdk.org/jextract/pull/265/files
  - new: https://git.openjdk.org/jextract/pull/265/files/c4079fdd..53801062

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

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

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

From nbenalla at openjdk.org  Wed Dec 18 17:43:27 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Dec 2024 17:43:27 GMT
Subject: RFR: 7903917: Changes needed for jdk23-based makefile build [v2]
In-Reply-To: <o70p55erwRr8F3_rszbbEab460g9Xs8tR0CGSx4iE_I=.90980f60-e89e-41dc-8660-3894768d6cd7@github.com>
References: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>
 <o70p55erwRr8F3_rszbbEab460g9Xs8tR0CGSx4iE_I=.90980f60-e89e-41dc-8660-3894768d6cd7@github.com>
Message-ID: <PtoQsN-4vlTYK4feM_p7o2KsuwweOIQKhhMFmTvXHKU=.cd16132b-c0d3-4f68-92ae-ac378d8729c7@github.com>

On Wed, 18 Dec 2024 16:25:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove --release flag
>
> make/Build.gmk line 50:
> 
>> 48: 	$(MKDIR) -p $(BUILD_CLASSES_DIR)/org/openjdk/jextract/impl
>> 49: 	$(FIXPATH) $(PANAMA_JAVA_HOME)/bin/javac \
>> 50: 	    --release=23 \
> 
> I suppose once we drop `--enable-preview` the `--release` flag can also be dropped, and will just default to the version of the JDK we are building with. This is fine as the same JDK is used to create the jextract runtime image.

Fixed in [5380106](https://github.com/openjdk/jextract/pull/265/commits/53801062000157c03e8ed0d8066dc8efceca161f) but it seems like we are bound to have a conflict after you integrate anyway, I tried a few things and would always end up with a conflict.

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

PR Review Comment: https://git.openjdk.org/jextract/pull/265#discussion_r1890616126

From mcimadamore at openjdk.org  Fri Dec 20 09:54:50 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Dec 2024 09:54:50 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions
In-Reply-To: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
Message-ID: <sk_9CtMcaDkqfo6DP-FxlfuqEQl-z3hm0A53GDbArM8=.b54d14aa-97f4-4ca6-a8ac-383ed7b259d2@github.com>

On Tue, 17 Dec 2024 13:35:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
> 
> There are 2 barriers to upgrading these JDK version to ones that are supported:
> 1. The current version of Gradle we are using doesn't run on newer Java versions
> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
> 
> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jextract/pull/264#pullrequestreview-2517177320

From mcimadamore at openjdk.org  Fri Dec 20 09:56:53 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Dec 2024 09:56:53 GMT
Subject: RFR: 7903735: Remove redundant method in generated code
In-Reply-To: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
References: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
Message-ID: <CBq9bvLmcvI0PQLtdDcaTa1SfyjkZ4bfV0TcEjrAwn4=.bc3e374f-e546-4167-be1a-0ba12432b7fa@github.com>

On Tue, 17 Dec 2024 18:39:19 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Was looking at older issues and saw an opportunity for a refractor.
> I don't see a dependent PR feature for this repo but this is meant to be merged after https://github.com/openjdk/jextract/pull/265

Looks like good consolidation. I'm not worried re. change in exception type, especially because in the new code the exception is more compliant with what FFM does.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jextract/pull/266#pullrequestreview-2517182780

From nbenalla at openjdk.org  Wed Dec 25 12:25:58 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 25 Dec 2024 12:25:58 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it was
 missed
Message-ID: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>

I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.


git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list


And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.

A few files had their original copyright year changed because I noticed they were added in 2024 instead.

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

Commit messages:
 - Manually fix files that were created on 11/01/24
 - Update (C) for 2024
 - Update (C) for 2023

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

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

From nbenalla at openjdk.org  Thu Dec 26 17:44:29 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 26 Dec 2024 17:44:29 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v2]
In-Reply-To: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
Message-ID: <ij6d99QY4UIZoPSfHcY6gZ9_2bfUhyqJbIy7fgDi68o=.26c2d792-818c-423f-ac9b-a1b6375a2950@github.com>

> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
> 
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
> 
> 
> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
> 
> A few files had their original copyright year changed because I noticed they were added in 2024 instead.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright of files changed in this PR to 2024

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

Changes:
  - all: https://git.openjdk.org/jextract/pull/267/files
  - new: https://git.openjdk.org/jextract/pull/267/files/2a4fb9e7..b8a76c59

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

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

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

From nbenalla at openjdk.org  Thu Dec 26 17:44:30 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 26 Dec 2024 17:44:30 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed
In-Reply-To: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
Message-ID: <dSj9WOrHOfP5T5t6DTIx5OMnydCoY8p5Zo92q8WhN44=.1338c922-db52-4de4-af53-409d453d6132@github.com>

On Wed, 25 Dec 2024 12:02:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
> 
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
> 
> 
> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
> 
> A few files had their original copyright year changed because I noticed they were added in 2024 instead.

I didn't think of this earlier but all files changed in this PR would need to use the 2024 copyright year too

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

PR Comment: https://git.openjdk.org/jextract/pull/267#issuecomment-2562980675

From nbenalla at openjdk.org  Thu Dec 26 17:56:18 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 26 Dec 2024 17:56:18 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v3]
In-Reply-To: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
Message-ID: <nOwJ3DEjfdH7ZF4PKqQwKgzlQ2eXKkpp7zzsR7HJoLw=.cafd820a-058a-4976-b084-edaecdd8efc7@github.com>

> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
> 
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
> 
> 
> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
> 
> A few files had their original copyright year changed because I noticed they were added in 2024 instead.

Nizar Benalla 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:

  - Manually fix files that were created on 11/01/24
  - Update copyright of files changed in this PR to 2024

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

Changes:
  - all: https://git.openjdk.org/jextract/pull/267/files
  - new: https://git.openjdk.org/jextract/pull/267/files/b8a76c59..918233e1

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

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

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

From nbenalla at openjdk.org  Thu Dec 26 17:56:18 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 26 Dec 2024 17:56:18 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v2]
In-Reply-To: <ij6d99QY4UIZoPSfHcY6gZ9_2bfUhyqJbIy7fgDi68o=.26c2d792-818c-423f-ac9b-a1b6375a2950@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <ij6d99QY4UIZoPSfHcY6gZ9_2bfUhyqJbIy7fgDi68o=.26c2d792-818c-423f-ac9b-a1b6375a2950@github.com>
Message-ID: <5FqysiOoz22lxFj8nBpAnXalsgHXpI4mKGGqPs4qSjc=.69c63776-f5f6-4d46-886a-9979f7f59adb@github.com>

On Thu, 26 Dec 2024 17:44:29 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
>> 
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
>> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
>> 
>> 
>> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
>> 
>> A few files had their original copyright year changed because I noticed they were added in 2024 instead.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright of files changed in this PR to 2024

Sorry for the force push, I had to update something.

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

PR Comment: https://git.openjdk.org/jextract/pull/267#issuecomment-2562988136

From nbenalla at openjdk.org  Mon Dec 30 16:23:21 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 30 Dec 2024 16:23:21 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker
Message-ID: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>

Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.

This patch can allows us to have a common class for different platforms.

Please review, and thanks in advance!

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

Commit messages:
 - derive "C" types directly from the linker

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

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

From duke at openjdk.org  Mon Dec 30 23:50:47 2024
From: duke at openjdk.org (Marcono1234)
Date: Mon, 30 Dec 2024 23:50:47 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions
In-Reply-To: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
Message-ID: <vWwLzuXE6QTzZaRmRikpqu-c0KGAppQxvfCMjpyxaW4=.c81bc929-4eb4-4a9d-84af-e96946936f25@github.com>

On Tue, 17 Dec 2024 13:35:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
> 
> There are 2 barriers to upgrading these JDK version to ones that are supported:
> 1. The current version of Gradle we are using doesn't run on newer Java versions
> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
> 
> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.

gradle/wrapper/gradle-wrapper.properties line 1:

> 1: distributionBase=GRADLE_USER_HOME

Do you want to update `gradle-wrapper.jar` and the `gradlew` scripts as well?

In that case you will have to run `./gradlew wrapper` a second time locally. See also https://docs.gradle.org/current/userguide/gradle_wrapper.html#sec:upgrading_wrapper.

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

PR Review Comment: https://git.openjdk.org/jextract/pull/264#discussion_r1899852427

From duke at openjdk.org  Tue Dec 31 00:09:47 2024
From: duke at openjdk.org (Marcono1234)
Date: Tue, 31 Dec 2024 00:09:47 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks
In-Reply-To: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
Message-ID: <U-Kvno0GNRn7ceR5PSy_YafBVN8ihdSGDdcHJcGg6wU=.7abda893-e626-43b2-ad7d-b1a7e2955469@github.com>

On Fri, 27 Dec 2024 17:38:32 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Read the JBS issue for more detail.
> 
> This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage`

The review comments below are only suggestions, feel free to ignore them, I am not a JDK member. Though hopefully the comments are useful nonetheless.

doc/GUIDE.md line 995:

> 993: | Option                       | Meaning                                                                                                                                                                                                                                 |
> 994: |:-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
> 995: | `--mac-framework-dir <dir>`  | specify the framework directory dir include files <br/>defaults to the current Mac OS X SDK dir<br/> This removes the need of having a compile_flags.txt with the required `-framework XYZ` options in the folder where jextract is ran |

Is this "directory dir" intentional?
Suggestion:

| `--mac-framework-dir <dir>`  | specify the framework directory include files <br/>defaults to the current Mac OS X SDK dir<br/> This removes the need of having a compile_flags.txt with the required `-framework XYZ` options in the folder where jextract is ran |

doc/GUIDE.md line 996:

> 994: |:-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
> 995: | `--mac-framework-dir <dir>`  | specify the framework directory dir include files <br/>defaults to the current Mac OS X SDK dir<br/> This removes the need of having a compile_flags.txt with the required `-framework XYZ` options in the folder where jextract is ran |
> 996: | `-f, framework <framekwork>` | specify the name of the library, path will be expanded to that of the framework folder                                                                                                                                                  |

Typo?
Suggestion:

| `-f, framework <framework>` | specify the name of the library, path will be expanded to that of the framework folder                                                                                                                                                  |

src/main/java/org/openjdk/jextract/JextractTool.java line 295:

> 293:         static boolean checkIfSupported( String option) {
> 294:             return platformOptions.contains(option);
> 295:         }

Maybe this name `checkIfSupported` (and the way the method is used below) is a bit misleading, the method just seems to return if this is a known platform option, so what about `isPlatformOption` instead?

src/main/java/org/openjdk/jextract/JextractTool.java line 387:

> 385:         parser.accepts("--version", "help.version", false);
> 386: 
> 387:         if(isMacOSX) {

Suggestion:

        if (isMacOSX) {

src/main/java/org/openjdk/jextract/JextractTool.java line 566:

> 564:                         builder.addLibrary(library);
> 565:                     } else {
> 566:                         // not an absolute path, but--use-system-load-library was specified

Suggestion:

                        // not an absolute path, but --use-system-load-library was specified

src/main/java/org/openjdk/jextract/JextractTool.java line 627:

> 625:     }
> 626: 
> 627:     private String parseFrameworkPath(String optionString) {

Maybe rename to `format...` since this is not parsing anything?
Suggestion:

    private String formatFrameworkPath(String optionString) {

src/main/java/org/openjdk/jextract/impl/Utils.java line 50:

> 48: import java.util.function.Consumer;
> 49: import java.util.regex.Matcher;
> 50: import java.util.regex.Pattern;

Unused imports?

src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties line 93:

> 91: Platform dependent options for running jextract                                                 \n\
> 92: --mac-framework-dir <dir>          specify the framework directory                              \n\
> 93: -f <framekwork>                    specify framework library. -f libGL is equivalent to         \n\

Suggestion:

-f <framework>                    specify framework library. -f libGL is equivalent to         \n\

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

PR Review: https://git.openjdk.org/jextract/pull/268#pullrequestreview-2526080122
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899854132
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899854182
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899854643
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899854842
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899855479
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899855778
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899855895
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899856061

From nbenalla at openjdk.org  Tue Dec 31 11:38:47 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 31 Dec 2024 11:38:47 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks
In-Reply-To: <U-Kvno0GNRn7ceR5PSy_YafBVN8ihdSGDdcHJcGg6wU=.7abda893-e626-43b2-ad7d-b1a7e2955469@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <U-Kvno0GNRn7ceR5PSy_YafBVN8ihdSGDdcHJcGg6wU=.7abda893-e626-43b2-ad7d-b1a7e2955469@github.com>
Message-ID: <_Di8Fnf2c4NIbkHP9xqDTXAtvSY9FXQkKA1zFbOBYLo=.de77159e-9a46-44b1-ae23-927c998a1476@github.com>

On Tue, 31 Dec 2024 00:06:57 GMT, Marcono1234 <duke at openjdk.org> wrote:

>> Read the JBS issue for more detail.
>> 
>> This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage`
>
> The review comments below are only suggestions, feel free to ignore them, I am not a JDK member. Though hopefully the comments are useful nonetheless.

Thanks @Marcono1234 for the comments. They were useful.

> doc/GUIDE.md line 995:
> 
>> 993: | Option                       | Meaning                                                                                                                                                                                                                                 |
>> 994: |:-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
>> 995: | `--mac-framework-dir <dir>`  | specify the framework directory dir include files <br/>defaults to the current Mac OS X SDK dir<br/> This removes the need of having a compile_flags.txt with the required `-framework XYZ` options in the folder where jextract is ran |
> 
> Is this "directory dir" intentional?
> Suggestion:
> 
> | `--mac-framework-dir <dir>`  | specify the framework directory include files <br/>defaults to the current Mac OS X SDK dir<br/> This removes the need of having a compile_flags.txt with the required `-framework XYZ` options in the folder where jextract is ran |

The apple gcc manual says

> -Fdir 
Add the framework directory dir to the head of the list of directories to be
searched for header files. These directories are interleaved with those specified
by -I options and are scanned in a left-to-right order.

I tried to follow similar conventions of C compilers

> src/main/java/org/openjdk/jextract/JextractTool.java line 295:
> 
>> 293:         static boolean checkIfSupported( String option) {
>> 294:             return platformOptions.contains(option);
>> 295:         }
> 
> Maybe this name `checkIfSupported` (and the way the method is used below) is a bit misleading, the method just seems to return if this is a known platform option, so what about `isPlatformOption` instead?

You're right, I copied the name from the `jpackage` sources but it's not very accurate.

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

PR Comment: https://git.openjdk.org/jextract/pull/268#issuecomment-2566373277
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1900067855
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1900068441

From nbenalla at openjdk.org  Tue Dec 31 12:24:25 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 31 Dec 2024 12:24:25 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v2]
In-Reply-To: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
Message-ID: <iuoCUIvKBcSZuBE3UdHeMKbhRaDe6y0_5cd7twzpfWY=.64b55bd2-761e-4450-812d-777e04cf79a4@github.com>

> Read the JBS issue for more detail.
> 
> This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage`

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos, rename some methods and bump copyright year to 2025

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

Changes:
  - all: https://git.openjdk.org/jextract/pull/268/files
  - new: https://git.openjdk.org/jextract/pull/268/files/efc469f0..aad02674

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

  Stats: 13 lines in 4 files changed: 1 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jextract/pull/268.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268

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

From duke at openjdk.org  Tue Dec 31 13:32:49 2024
From: duke at openjdk.org (Marcono1234)
Date: Tue, 31 Dec 2024 13:32:49 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v2]
In-Reply-To: <iuoCUIvKBcSZuBE3UdHeMKbhRaDe6y0_5cd7twzpfWY=.64b55bd2-761e-4450-812d-777e04cf79a4@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <iuoCUIvKBcSZuBE3UdHeMKbhRaDe6y0_5cd7twzpfWY=.64b55bd2-761e-4450-812d-777e04cf79a4@github.com>
Message-ID: <PCuaWJoHCm_4FAIMwQz8EPIqzwyZ1ut9UoXrB-dwBkQ=.7fd05c6f-3a80-4f9c-b4c9-da2e5dfbae8b@github.com>

On Tue, 31 Dec 2024 12:24:25 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Read the JBS issue for more detail.
>> 
>> This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage`
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos, rename some methods and bump copyright year to 2025

src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties line 94:

> 92: --mac-framework-dir <dir>          specify the framework directory                              \n\
> 93: -f <framework>                    specify framework library. -f libGL is equivalent to         \n\
> 94: \                                      -l :/System/Library/Frameworks/libGL.framework/libGL         \n

Wrong / inconsistent indentation?
Suggestion:

-f <framework>                     specify framework library. -f libGL is equivalent to         \n\
\                                   -l :/System/Library/Frameworks/libGL.framework/libGL       \n

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

PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1900114511