From mcimadamore at openjdk.org  Fri Jul  1 12:33:41 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 1 Jul 2022 12:33:41 GMT
Subject: RFR: 7903209: Handle lifecycle of libclang abstractions more
 explicitly [v2]
In-Reply-To: <G9Yw_CpzU1XWLl1a395s_dQgqQeIv9Eau4zQMLtlKDU=.5211da2f-e375-45ae-ac11-404e836b9771@github.com>
References: <G9Yw_CpzU1XWLl1a395s_dQgqQeIv9Eau4zQMLtlKDU=.5211da2f-e375-45ae-ac11-404e836b9771@github.com>
Message-ID: <MhBFdF9NsmIsAlHt5GhX56uyZEqPZZrQgX_AuFN6Nts=.74c17bad-f098-41f7-930d-03e357bc2590@github.com>

> This patch clarifies the lifecycle of the entities generated by jextract. The main changes are two:
> 
> 1. First, instead of "buffering" cursors in the `Cursor.children` method, so that a `Stream` can be returned, it instead accepts an action which will be executed for each visited cursor. This allows us to get rid of the buffering code, but at the same time it means that the downstream code has to be careful: any attempt to cache the cursor into a field, and access it _after_ the visitor has completed wil result in issues.
> 
> 2. Secondly, it replaces uses of implicit session and implicit allocator almost everywhere. There are two main lifecycle entities: index and translation unit (there are others too, but these are the main ones). Translation units are created inside an index lifetime, whereas cursors and types are created inside the translation unit lifetime. This patch makes this organization clear, by adding a new type called `ClangDisposable`, an entity that has a session, and an associated arena allocator - and an `Owned` an entity that is owned by some `ClangDisposable` (and so it can use its arena to perform allocation). This scheme is relatively simple, but at the same time quite expressive, and helps keeping the complexity in check.
> 
> As a result, most of the allocation now occurs in a confined scope, with clear lifetime boundaries. Any  attemp to access e.g. a cursor after its translation unit is gone will result in an exception. I believe this can be quite useful to catch latent lifecycle issues in the code (I already fixed a few when working on this patch).

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into cursor_visit_nocopy
 - Fix whitespaces
 - Remove IMPLICIT_ALLOCATOR constant, so that we don't accidentally depend on it
 - Add copyright
 - Various cleanups
   Added more doc
 - Add explicit management of libclang abstractions lifetime
 - Initial push

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

Changes:
  - all: https://git.openjdk.org/jextract/pull/48/files
  - new: https://git.openjdk.org/jextract/pull/48/files/46ba0eb2..d38470c5

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

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

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

From sundar at openjdk.org  Fri Jul  1 12:52:59 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 1 Jul 2022 12:52:59 GMT
Subject: RFR: 7903209: Handle lifecycle of libclang abstractions more
 explicitly [v2]
In-Reply-To: <MhBFdF9NsmIsAlHt5GhX56uyZEqPZZrQgX_AuFN6Nts=.74c17bad-f098-41f7-930d-03e357bc2590@github.com>
References: <G9Yw_CpzU1XWLl1a395s_dQgqQeIv9Eau4zQMLtlKDU=.5211da2f-e375-45ae-ac11-404e836b9771@github.com>
 <MhBFdF9NsmIsAlHt5GhX56uyZEqPZZrQgX_AuFN6Nts=.74c17bad-f098-41f7-930d-03e357bc2590@github.com>
Message-ID: <RNN_s9uEoXRGdGzVsELcJsk9ukNidSPoRfRD5nBj3BY=.e5566030-c21a-4dd6-bebe-d92ea45133e0@github.com>

On Fri, 1 Jul 2022 12:33:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch clarifies the lifecycle of the entities generated by jextract. The main changes are two:
>> 
>> 1. First, instead of "buffering" cursors in the `Cursor.children` method, so that a `Stream` can be returned, it instead accepts an action which will be executed for each visited cursor. This allows us to get rid of the buffering code, but at the same time it means that the downstream code has to be careful: any attempt to cache the cursor into a field, and access it _after_ the visitor has completed wil result in issues.
>> 
>> 2. Secondly, it replaces uses of implicit session and implicit allocator almost everywhere. There are two main lifecycle entities: index and translation unit (there are others too, but these are the main ones). Translation units are created inside an index lifetime, whereas cursors and types are created inside the translation unit lifetime. This patch makes this organization clear, by adding a new type called `ClangDisposable`, an entity that has a session, and an associated arena allocator - and an `Owned` an entity that is owned by some `ClangDisposable` (and so it can use its arena to perform allocation). This scheme is relatively simple, but at the same time quite expressive, and helps keeping the complexity in check.
>> 
>> As a result, most of the allocation now occurs in a confined scope, with clear lifetime boundaries. Any  attemp to access e.g. a cursor after its translation unit is gone will result in an exception. I believe this can be quite useful to catch latent lifecycle issues in the code (I already fixed a few when working on this patch).
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into cursor_visit_nocopy
>  - Fix whitespaces
>  - Remove IMPLICIT_ALLOCATOR constant, so that we don't accidentally depend on it
>  - Add copyright
>  - Various cleanups
>    Added more doc
>  - Add explicit management of libclang abstractions lifetime
>  - Initial push

LGTM

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

Marked as reviewed by sundar (Committer).

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

From mcimadamore at openjdk.org  Fri Jul  1 13:30:53 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 1 Jul 2022 13:30:53 GMT
Subject: RFR: 7903209: Handle lifecycle of libclang abstractions more
 explicitly [v3]
In-Reply-To: <G9Yw_CpzU1XWLl1a395s_dQgqQeIv9Eau4zQMLtlKDU=.5211da2f-e375-45ae-ac11-404e836b9771@github.com>
References: <G9Yw_CpzU1XWLl1a395s_dQgqQeIv9Eau4zQMLtlKDU=.5211da2f-e375-45ae-ac11-404e836b9771@github.com>
Message-ID: <nRvsj5Mme8_BP-uBkwKp8eK3KaBC2k85-uJH0NVjujQ=.feec2689-26a0-4946-9585-b80502fc3edf@github.com>

> This patch clarifies the lifecycle of the entities generated by jextract. The main changes are two:
> 
> 1. First, instead of "buffering" cursors in the `Cursor.children` method, so that a `Stream` can be returned, it instead accepts an action which will be executed for each visited cursor. This allows us to get rid of the buffering code, but at the same time it means that the downstream code has to be careful: any attempt to cache the cursor into a field, and access it _after_ the visitor has completed wil result in issues.
> 
> 2. Secondly, it replaces uses of implicit session and implicit allocator almost everywhere. There are two main lifecycle entities: index and translation unit (there are others too, but these are the main ones). Translation units are created inside an index lifetime, whereas cursors and types are created inside the translation unit lifetime. This patch makes this organization clear, by adding a new type called `ClangDisposable`, an entity that has a session, and an associated arena allocator - and an `Owned` an entity that is owned by some `ClangDisposable` (and so it can use its arena to perform allocation). This scheme is relatively simple, but at the same time quite expressive, and helps keeping the complexity in check.
> 
> As a result, most of the allocation now occurs in a confined scope, with clear lifetime boundaries. Any  attemp to access e.g. a cursor after its translation unit is gone will result in an exception. I believe this can be quite useful to catch latent lifecycle issues in the code (I already fixed a few when working on this patch).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Make ClangDisposeable implement SegmentAllocator, and simplify code

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

Changes:
  - all: https://git.openjdk.org/jextract/pull/48/files
  - new: https://git.openjdk.org/jextract/pull/48/files/d38470c5..2428b85f

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

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

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

From sundar at openjdk.org  Fri Jul  1 13:38:00 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Fri, 1 Jul 2022 13:38:00 GMT
Subject: RFR: 7903209: Handle lifecycle of libclang abstractions more
 explicitly [v3]
In-Reply-To: <nRvsj5Mme8_BP-uBkwKp8eK3KaBC2k85-uJH0NVjujQ=.feec2689-26a0-4946-9585-b80502fc3edf@github.com>
References: <G9Yw_CpzU1XWLl1a395s_dQgqQeIv9Eau4zQMLtlKDU=.5211da2f-e375-45ae-ac11-404e836b9771@github.com>
 <nRvsj5Mme8_BP-uBkwKp8eK3KaBC2k85-uJH0NVjujQ=.feec2689-26a0-4946-9585-b80502fc3edf@github.com>
Message-ID: <qz0ru80nlgcw6v8sttHLziRjheR20-p9L2PuRiHhcz8=.0b5c27aa-682b-4c75-bed7-e4e02c47d799@github.com>

On Fri, 1 Jul 2022 13:30:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch clarifies the lifecycle of the entities generated by jextract. The main changes are two:
>> 
>> 1. First, instead of "buffering" cursors in the `Cursor.children` method, so that a `Stream` can be returned, it instead accepts an action which will be executed for each visited cursor. This allows us to get rid of the buffering code, but at the same time it means that the downstream code has to be careful: any attempt to cache the cursor into a field, and access it _after_ the visitor has completed wil result in issues.
>> 
>> 2. Secondly, it replaces uses of implicit session and implicit allocator almost everywhere. There are two main lifecycle entities: index and translation unit (there are others too, but these are the main ones). Translation units are created inside an index lifetime, whereas cursors and types are created inside the translation unit lifetime. This patch makes this organization clear, by adding a new type called `ClangDisposable`, an entity that has a session, and an associated arena allocator - and an `Owned` an entity that is owned by some `ClangDisposable` (and so it can use its arena to perform allocation). This scheme is relatively simple, but at the same time quite expressive, and helps keeping the complexity in check.
>> 
>> As a result, most of the allocation now occurs in a confined scope, with clear lifetime boundaries. Any  attemp to access e.g. a cursor after its translation unit is gone will result in an exception. I believe this can be quite useful to catch latent lifecycle issues in the code (I already fixed a few when working on this patch).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make ClangDisposeable implement SegmentAllocator, and simplify code

Additional changes are fine.

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

Marked as reviewed by sundar (Committer).

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

From mcimadamore at openjdk.org  Fri Jul  1 14:18:59 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 1 Jul 2022 14:18:59 GMT
Subject: Integrated: 7903209: Handle lifecycle of libclang abstractions more
 explicitly
In-Reply-To: <G9Yw_CpzU1XWLl1a395s_dQgqQeIv9Eau4zQMLtlKDU=.5211da2f-e375-45ae-ac11-404e836b9771@github.com>
References: <G9Yw_CpzU1XWLl1a395s_dQgqQeIv9Eau4zQMLtlKDU=.5211da2f-e375-45ae-ac11-404e836b9771@github.com>
Message-ID: <Tj-rUdzr5A5HWCToRwvWSFvC2AIq4utlmJBl1o2cTnk=.5a78f079-ed88-4618-a367-816ca5676f4e@github.com>

On Fri, 10 Jun 2022 21:44:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch clarifies the lifecycle of the entities generated by jextract. The main changes are two:
> 
> 1. First, instead of "buffering" cursors in the `Cursor.children` method, so that a `Stream` can be returned, it instead accepts an action which will be executed for each visited cursor. This allows us to get rid of the buffering code, but at the same time it means that the downstream code has to be careful: any attempt to cache the cursor into a field, and access it _after_ the visitor has completed wil result in issues.
> 
> 2. Secondly, it replaces uses of implicit session and implicit allocator almost everywhere. There are two main lifecycle entities: index and translation unit (there are others too, but these are the main ones). Translation units are created inside an index lifetime, whereas cursors and types are created inside the translation unit lifetime. This patch makes this organization clear, by adding a new type called `ClangDisposable`, an entity that has a session, and an associated arena allocator - and an `Owned` an entity that is owned by some `ClangDisposable` (and so it can use its arena to perform allocation). This scheme is relatively simple, but at the same time quite expressive, and helps keeping the complexity in check.
> 
> As a result, most of the allocation now occurs in a confined scope, with clear lifetime boundaries. Any  attemp to access e.g. a cursor after its translation unit is gone will result in an exception. I believe this can be quite useful to catch latent lifecycle issues in the code (I already fixed a few when working on this patch).

This pull request has now been integrated.

Changeset: e2d3b874
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/e2d3b87468a4ecf8e6299d60ce8a04ad66c74b55
Stats:     556 lines in 16 files changed: 178 ins; 123 del; 255 mod

7903209: Handle lifecycle of libclang abstractions more explicitly

Reviewed-by: sundar

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

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

From sundar at openjdk.org  Tue Jul  5 10:45:17 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 5 Jul 2022 10:45:17 GMT
Subject: RFR: Revert "7903198: Refine filtering for enums"
Message-ID: <l3ItN9rbsN6z64ykG_lpYXWzWzN2DoQbQxddEwNDAc4=.2957f430-b87f-48c0-b93d-2c35cc123436@github.com>

This reverts commit c2f1359c46728e3787bf0b0316c8078edd63ff7b.

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

Commit messages:
 - Revert "7903198: Refine filtering for enums"

Changes: https://git.openjdk.org/jextract/pull/50/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=50&range=00
  Stats: 46 lines in 6 files changed: 4 ins; 24 del; 18 mod
  Patch: https://git.openjdk.org/jextract/pull/50.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/50/head:pull/50

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

From mcimadamore at openjdk.org  Tue Jul  5 10:53:55 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 5 Jul 2022 10:53:55 GMT
Subject: RFR: Revert "7903198: Refine filtering for enums"
In-Reply-To: <l3ItN9rbsN6z64ykG_lpYXWzWzN2DoQbQxddEwNDAc4=.2957f430-b87f-48c0-b93d-2c35cc123436@github.com>
References: <l3ItN9rbsN6z64ykG_lpYXWzWzN2DoQbQxddEwNDAc4=.2957f430-b87f-48c0-b93d-2c35cc123436@github.com>
Message-ID: <R-TE1Y9mKuFRH095PmydbHkFejy5TBB0gjZ7qXn1EHg=.0eff88fb-6110-469c-8c7d-f474c99adb61@github.com>

On Tue, 5 Jul 2022 10:39:21 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> This reverts commit c2f1359c46728e3787bf0b0316c8078edd63ff7b.

Looks good

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

Marked as reviewed by mcimadamore (Committer).

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

From sundar at openjdk.org  Tue Jul  5 11:02:03 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 5 Jul 2022 11:02:03 GMT
Subject: Integrated: Revert "7903198: Refine filtering for enums"
In-Reply-To: <l3ItN9rbsN6z64ykG_lpYXWzWzN2DoQbQxddEwNDAc4=.2957f430-b87f-48c0-b93d-2c35cc123436@github.com>
References: <l3ItN9rbsN6z64ykG_lpYXWzWzN2DoQbQxddEwNDAc4=.2957f430-b87f-48c0-b93d-2c35cc123436@github.com>
Message-ID: <kLB3JToJi9phfk_dnJPgWk0AxfUleqCFowbKbwvu0M8=.66e27dfb-ff06-4c06-926e-23a8c167a54c@github.com>

On Tue, 5 Jul 2022 10:39:21 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> This reverts commit c2f1359c46728e3787bf0b0316c8078edd63ff7b.

This pull request has now been integrated.

Changeset: 80079356
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/800793568f71cc2d8071484d9a7c17970d578892
Stats:     46 lines in 6 files changed: 4 ins; 24 del; 18 mod

Revert "7903198: Refine filtering for enums"

Reviewed-by: mcimadamore

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

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

From sundar at openjdk.org  Tue Jul  5 11:12:22 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 5 Jul 2022 11:12:22 GMT
Subject: RFR: Revert "7903198: Refine filtering for enums"
Message-ID: <BVJyjsIslvEtUGl_RXruzc_EqjavN0bYFqwxUW25gVU=.cc28d789-a467-4498-ab68-b1fe5c3bf184@github.com>

This reverts commit 5e51e03329e11c0db977f58d698e1f8cc42b2463.

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

Commit messages:
 - Revert "7903198: Refine filtering for enums"

Changes: https://git.openjdk.org/jextract/pull/51/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=51&range=00
  Stats: 47 lines in 6 files changed: 5 ins; 24 del; 18 mod
  Patch: https://git.openjdk.org/jextract/pull/51.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/51/head:pull/51

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

From mcimadamore at openjdk.org  Tue Jul  5 11:41:52 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 5 Jul 2022 11:41:52 GMT
Subject: RFR: Revert "7903198: Refine filtering for enums"
In-Reply-To: <BVJyjsIslvEtUGl_RXruzc_EqjavN0bYFqwxUW25gVU=.cc28d789-a467-4498-ab68-b1fe5c3bf184@github.com>
References: <BVJyjsIslvEtUGl_RXruzc_EqjavN0bYFqwxUW25gVU=.cc28d789-a467-4498-ab68-b1fe5c3bf184@github.com>
Message-ID: <sT4pnYqn78eHPYSoIBlX4sC_8FIf73Yg6n1HQU57Uok=.46f08494-8986-4ac8-bf96-0d5e0c798cc8@github.com>

On Tue, 5 Jul 2022 11:06:49 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> This reverts commit 5e51e03329e11c0db977f58d698e1f8cc42b2463.

Looks good

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

Marked as reviewed by mcimadamore (Committer).

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

From sundar at openjdk.org  Tue Jul  5 11:46:10 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 5 Jul 2022 11:46:10 GMT
Subject: Integrated: Revert "7903198: Refine filtering for enums"
In-Reply-To: <BVJyjsIslvEtUGl_RXruzc_EqjavN0bYFqwxUW25gVU=.cc28d789-a467-4498-ab68-b1fe5c3bf184@github.com>
References: <BVJyjsIslvEtUGl_RXruzc_EqjavN0bYFqwxUW25gVU=.cc28d789-a467-4498-ab68-b1fe5c3bf184@github.com>
Message-ID: <TbkR_4EndisSfs329eqZhtncsqjQr7dXbF9-C6s-mFQ=.af763b39-4ed7-4b33-ae6f-31e2b08ff44c@github.com>

On Tue, 5 Jul 2022 11:06:49 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> This reverts commit 5e51e03329e11c0db977f58d698e1f8cc42b2463.

This pull request has now been integrated.

Changeset: faa3138f
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/faa3138f194e2d856c06ce3a76e47fd533573491
Stats:     47 lines in 6 files changed: 5 ins; 24 del; 18 mod

Revert "7903198: Refine filtering for enums"

Reviewed-by: mcimadamore

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

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

From sundar at openjdk.org  Tue Jul  5 12:28:29 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 5 Jul 2022 12:28:29 GMT
Subject: RFR: updating libclang binding for jetract changes and llvm 13.0.0
Message-ID: <6IZpktRMgi5Gd9_J5ZPH900go3Z-Pq9Z2qAhQkAPDQU=.bf0cc398-10fb-4f5e-b810-16677aa6ce78@github.com>

regenerating LibClang binding for jextract changes and llvm 13.0.0

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

Commit messages:
 - updating libclang binding for jetract changes and llvm 13.0.0

Changes: https://git.openjdk.org/jextract/pull/52/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=52&range=00
  Stats: 250 lines in 22 files changed: 6 ins; 9 del; 235 mod
  Patch: https://git.openjdk.org/jextract/pull/52.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/52/head:pull/52

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

From jvernee at openjdk.org  Tue Jul  5 12:39:59 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 5 Jul 2022 12:39:59 GMT
Subject: RFR: updating libclang binding for jetract changes and llvm 13.0.0
In-Reply-To: <6IZpktRMgi5Gd9_J5ZPH900go3Z-Pq9Z2qAhQkAPDQU=.bf0cc398-10fb-4f5e-b810-16677aa6ce78@github.com>
References: <6IZpktRMgi5Gd9_J5ZPH900go3Z-Pq9Z2qAhQkAPDQU=.bf0cc398-10fb-4f5e-b810-16677aa6ce78@github.com>
Message-ID: <aXCTsPwUJJOmDvjm7v75erIWlF7WgGkemI14SBdbt8E=.96fac382-db21-4e46-a473-0ef828396950@github.com>

On Tue, 5 Jul 2022 12:22:21 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> regenerating LibClang binding for jextract changes and llvm 13.0.0

src/main/java/org/openjdk/jextract/clang/libclang/RuntimeHelper.java line 65:

> 63: 
> 64:     static {
> 65:         System.loadLibrary("clang");

This needs the fix for Windows

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

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

From sundar at openjdk.org  Tue Jul  5 13:02:53 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 5 Jul 2022 13:02:53 GMT
Subject: RFR: updating libclang binding for jextract changes and llvm
 13.0.0
In-Reply-To: <aXCTsPwUJJOmDvjm7v75erIWlF7WgGkemI14SBdbt8E=.96fac382-db21-4e46-a473-0ef828396950@github.com>
References: <6IZpktRMgi5Gd9_J5ZPH900go3Z-Pq9Z2qAhQkAPDQU=.bf0cc398-10fb-4f5e-b810-16677aa6ce78@github.com>
 <aXCTsPwUJJOmDvjm7v75erIWlF7WgGkemI14SBdbt8E=.96fac382-db21-4e46-a473-0ef828396950@github.com>
Message-ID: <WxXN2bpTnRHmSQMqhe28H7QX2JEGdA39XfPh-p-PRrY=.ab7662d6-cdd5-4db7-b3ed-dfceaee926a6@github.com>

On Tue, 5 Jul 2022 12:36:48 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> regenerating LibClang binding for jextract changes and llvm 13.0.0
>
> src/main/java/org/openjdk/jextract/clang/libclang/RuntimeHelper.java line 65:
> 
>> 63: 
>> 64:     static {
>> 65:         System.loadLibrary("clang");
> 
> This needs the fix for Windows

oops. missed that manual change. will fix it.

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

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

From mcimadamore at openjdk.org  Tue Jul  5 13:13:50 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 5 Jul 2022 13:13:50 GMT
Subject: RFR: updating libclang binding for jextract changes and llvm
 13.0.0 [v2]
In-Reply-To: <05TL6GVXxO0J_BM931iwogtIoeHU11v4Id1TLVh_jTQ=.0ca32068-4f34-4c5c-bfc5-131b643cbd55@github.com>
References: <6IZpktRMgi5Gd9_J5ZPH900go3Z-Pq9Z2qAhQkAPDQU=.bf0cc398-10fb-4f5e-b810-16677aa6ce78@github.com>
 <05TL6GVXxO0J_BM931iwogtIoeHU11v4Id1TLVh_jTQ=.0ca32068-4f34-4c5c-bfc5-131b643cbd55@github.com>
Message-ID: <UiKOc7nNL8aaZdQ_KdqRqUVzp_V49C3ocHZCz0INsXI=.0b8f31bc-5e44-41db-b47a-cf7d9e3980f6@github.com>

On Tue, 5 Jul 2022 13:10:16 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> regenerating LibClang binding for jextract changes and llvm 13.0.0
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed library name for Windows (review comment)

Looks good

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

Marked as reviewed by mcimadamore (Committer).

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

From sundar at openjdk.org  Tue Jul  5 13:13:50 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 5 Jul 2022 13:13:50 GMT
Subject: RFR: updating libclang binding for jextract changes and llvm
 13.0.0 [v2]
In-Reply-To: <6IZpktRMgi5Gd9_J5ZPH900go3Z-Pq9Z2qAhQkAPDQU=.bf0cc398-10fb-4f5e-b810-16677aa6ce78@github.com>
References: <6IZpktRMgi5Gd9_J5ZPH900go3Z-Pq9Z2qAhQkAPDQU=.bf0cc398-10fb-4f5e-b810-16677aa6ce78@github.com>
Message-ID: <05TL6GVXxO0J_BM931iwogtIoeHU11v4Id1TLVh_jTQ=.0ca32068-4f34-4c5c-bfc5-131b643cbd55@github.com>

> regenerating LibClang binding for jextract changes and llvm 13.0.0

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  fixed library name for Windows (review comment)

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

Changes:
  - all: https://git.openjdk.org/jextract/pull/52/files
  - new: https://git.openjdk.org/jextract/pull/52/files/161516ac..432fcb0e

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

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

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

From sundar at openjdk.org  Tue Jul  5 13:28:01 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 5 Jul 2022 13:28:01 GMT
Subject: Integrated: updating libclang binding for jextract changes and llvm
 13.0.0
In-Reply-To: <6IZpktRMgi5Gd9_J5ZPH900go3Z-Pq9Z2qAhQkAPDQU=.bf0cc398-10fb-4f5e-b810-16677aa6ce78@github.com>
References: <6IZpktRMgi5Gd9_J5ZPH900go3Z-Pq9Z2qAhQkAPDQU=.bf0cc398-10fb-4f5e-b810-16677aa6ce78@github.com>
Message-ID: <UIQV4yfYDLsoj5_K7hmn9QKwh3VUgr8V3pAJxh43aYg=.9376fa76-c32e-4ad6-9c2a-c5d9122fb5b1@github.com>

On Tue, 5 Jul 2022 12:22:21 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> regenerating LibClang binding for jextract changes and llvm 13.0.0

This pull request has now been integrated.

Changeset: 5280c155
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/5280c1555bb878e5b03a2d377d055546cd293563
Stats:     247 lines in 22 files changed: 7 ins; 7 del; 233 mod

updating libclang binding for jextract changes and llvm 13.0.0

Reviewed-by: mcimadamore

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

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

From sundar at openjdk.org  Tue Jul  5 14:09:33 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 5 Jul 2022 14:09:33 GMT
Subject: RFR: updating libclang binding for jextract changes and llvm 13.0.0
Message-ID: <xnyBjC92xFyECCHvRR6QDEtLDXd3cBIJgeZf9LZ1M0E=.df1935a4-0c75-4226-b0eb-ba07b872a1dd@github.com>

backport of same change from jdk19 master branch

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

Commit messages:
 - updating libclang binding for jextract changes and llvm 13.0.0

Changes: https://git.openjdk.org/jextract/pull/53/files
 Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=53&range=00
  Stats: 245 lines in 22 files changed: 6 ins; 7 del; 232 mod
  Patch: https://git.openjdk.org/jextract/pull/53.diff
  Fetch: git fetch https://git.openjdk.org/jextract pull/53/head:pull/53

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

From duncan.gittins at gmail.com  Fri Jul  8 15:03:02 2022
From: duncan.gittins at gmail.com (Duncan Gittins)
Date: Fri, 8 Jul 2022 16:03:02 +0100
Subject: RFR: updating libclang binding for jetract changes and llvm 13.0.0
In-Reply-To: <aXCTsPwUJJOmDvjm7v75erIWlF7WgGkemI14SBdbt8E=.96fac382-db21-4e46-a473-0ef828396950@github.com>
References: <6IZpktRMgi5Gd9_J5ZPH900go3Z-Pq9Z2qAhQkAPDQU=.bf0cc398-10fb-4f5e-b810-16677aa6ce78@github.com>
 <aXCTsPwUJJOmDvjm7v75erIWlF7WgGkemI14SBdbt8E=.96fac382-db21-4e46-a473-0ef828396950@github.com>
Message-ID: <CABOqcFuzDobOauiK_FRnNtNUkPWpYpEnw=YGfXiioiSD_nb=7Q@mail.gmail.com>

Given this manual RuntimeHelper.java fix is applied to generated code each
time and so might recur, is there a reason that the fix isn't applied to
non-generated code - say LibClang.java?

    static {
        // Manual change to handle platform specific library name difference
        String libName = System.getProperty("os.name").startsWith("Windows")?
"libclang" : "clang";
        System.loadLibrary(libName);
    }

Kind regards

Duncan





On Wed, 6 Jul 2022 at 07:30, Jorn Vernee <jvernee at openjdk.org> wrote:

> On Tue, 5 Jul 2022 12:22:21 GMT, Athijegannathan Sundararajan <
> sundar at openjdk.org> wrote:
>
> > regenerating LibClang binding for jextract changes and llvm 13.0.0
>
> src/main/java/org/openjdk/jextract/clang/libclang/RuntimeHelper.java line
> 65:
>
> > 63:
> > 64:     static {
> > 65:         System.loadLibrary("clang");
>
> This needs the fix for Windows
>
> -------------
>
> PR: https://git.openjdk.org/jextract/pull/52
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20220708/1875a13d/attachment.htm>

From mcimadamore at openjdk.org  Mon Jul 11 09:15:07 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 11 Jul 2022 09:15:07 GMT
Subject: RFR: updating libclang binding for jextract changes and llvm
 13.0.0
In-Reply-To: <xnyBjC92xFyECCHvRR6QDEtLDXd3cBIJgeZf9LZ1M0E=.df1935a4-0c75-4226-b0eb-ba07b872a1dd@github.com>
References: <xnyBjC92xFyECCHvRR6QDEtLDXd3cBIJgeZf9LZ1M0E=.df1935a4-0c75-4226-b0eb-ba07b872a1dd@github.com>
Message-ID: <L8UMojkmzd5RSu-5JWb-AfkVvt_KBRckVX4S7gbsbl8=.a66c22f4-4e67-45a9-83e3-0d5013754b71@github.com>

On Tue, 5 Jul 2022 14:02:57 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> backport of same change from jdk19 master branch

Marked as reviewed by mcimadamore (Committer).

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

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

From sundar at openjdk.org  Mon Jul 11 12:18:03 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Mon, 11 Jul 2022 12:18:03 GMT
Subject: Integrated: updating libclang binding for jextract changes and llvm
 13.0.0
In-Reply-To: <xnyBjC92xFyECCHvRR6QDEtLDXd3cBIJgeZf9LZ1M0E=.df1935a4-0c75-4226-b0eb-ba07b872a1dd@github.com>
References: <xnyBjC92xFyECCHvRR6QDEtLDXd3cBIJgeZf9LZ1M0E=.df1935a4-0c75-4226-b0eb-ba07b872a1dd@github.com>
Message-ID: <nc_QjxjkrVc03IGO-qKg5qDqIOM8fnuB36gr6fvMerU=.932ae7bd-1ce1-4f55-a07b-81200d5bed81@github.com>

On Tue, 5 Jul 2022 14:02:57 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> backport of same change from jdk19 master branch

This pull request has now been integrated.

Changeset: 2bb7915b
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/2bb7915bad665532f247ca0dd9355d8d9e77c7f4
Stats:     245 lines in 22 files changed: 6 ins; 7 del; 232 mod

updating libclang binding for jextract changes and llvm 13.0.0

Reviewed-by: mcimadamore

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

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

From im at lostillusion.net  Sun Jul 17 03:28:39 2022
From: im at lostillusion.net (Lost Illusion)
Date: Sat, 16 Jul 2022 23:28:39 -0400
Subject: BUG: function pointer as struct member does not compile if name is
 same as the struct
Message-ID: <CAHFdwNYHsM9tJAqSxmuHe77D+RH4=91P8KG_xDjwOHwjpESPUQ@mail.gmail.com>

Hello,
I'm currently using jextract in tandem with Kotlin/Native's ability to
generate shared libraries and header files. It works nicely until you
add a class to the Kotlin code which generates a struct and a function
pointer (the initializer for the class) as a struct member, with both
having the same name. Here's a minimal header file with the same
problem.
test.h:
```
struct {
    int (*Foo)();
} Foo;
```
While this is valid for a header file, jextract has a problem
processing it. Using the latest jextract on the jdk18 branch, and
using the following command: `jextract test.h`. I get bombarded with
11 errors about resolving symbols and a duplicate class. Seems to be
because a static class for the struct Foo is generated and an
interface for the method Foo is also generated. I'm new to the project
and not sure what the correct behavior should be in order to fix this
issue.

From maurizio.cimadamore at oracle.com  Mon Jul 18 09:28:34 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 18 Jul 2022 10:28:34 +0100
Subject: BUG: function pointer as struct member does not compile if name
 is same as the struct
In-Reply-To: <CAHFdwNYHsM9tJAqSxmuHe77D+RH4=91P8KG_xDjwOHwjpESPUQ@mail.gmail.com>
References: <CAHFdwNYHsM9tJAqSxmuHe77D+RH4=91P8KG_xDjwOHwjpESPUQ@mail.gmail.com>
Message-ID: <f13d4033-788d-a93d-94c9-1fe585ccbedf@oracle.com>

Hi,
I can reproduce even with explicit struct name:

```
struct Foo {
 ??? int (*Foo)();
};
```

I'll leave this to Sundar - my feeling is that the code in Output helper 
that handles function pointers does not check for clashes with the 
surrounding scope; we perform such checks when nesting structs inside 
other structs, but apparently the name clash logic is missing for 
function pointers.

Maurizio

On 17/07/2022 04:28, Lost Illusion wrote:
> Hello,
> I'm currently using jextract in tandem with Kotlin/Native's ability to
> generate shared libraries and header files. It works nicely until you
> add a class to the Kotlin code which generates a struct and a function
> pointer (the initializer for the class) as a struct member, with both
> having the same name. Here's a minimal header file with the same
> problem.
> test.h:
> ```
> struct {
>      int (*Foo)();
> } Foo;
> ```
> While this is valid for a header file, jextract has a problem
> processing it. Using the latest jextract on the jdk18 branch, and
> using the following command: `jextract test.h`. I get bombarded with
> 11 errors about resolving symbols and a duplicate class. Seems to be
> because a static class for the struct Foo is generated and an
> interface for the method Foo is also generated. I'm new to the project
> and not sure what the correct behavior should be in order to fix this
> issue.

From sundararajan.athijegannathan at oracle.com  Tue Jul 19 10:19:10 2022
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 19 Jul 2022 10:19:10 +0000
Subject: BUG: function pointer as struct member does not compile if name
 is same as the struct
In-Reply-To: <f13d4033-788d-a93d-94c9-1fe585ccbedf@oracle.com>
References: <CAHFdwNYHsM9tJAqSxmuHe77D+RH4=91P8KG_xDjwOHwjpESPUQ@mail.gmail.com>
 <f13d4033-788d-a93d-94c9-1fe585ccbedf@oracle.com>
Message-ID: <DM6PR10MB295499496861E0E93759763DEA8F9@DM6PR10MB2954.namprd10.prod.outlook.com>

Hi,

Thanks for reporting this issue. I've filed a bug:

https://bugs.openjdk.org/browse/CODETOOLS-7903237

Thanks
-Sundar
________________________________
From: jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
Sent: 18 July 2022 14:58
To: Lost Illusion <im at lostillusion.net>; jextract-dev at openjdk.org <jextract-dev at openjdk.org>
Subject: Re: BUG: function pointer as struct member does not compile if name is same as the struct

Hi,
I can reproduce even with explicit struct name:

```
struct Foo {
     int (*Foo)();
};
```

I'll leave this to Sundar - my feeling is that the code in Output helper
that handles function pointers does not check for clashes with the
surrounding scope; we perform such checks when nesting structs inside
other structs, but apparently the name clash logic is missing for
function pointers.

Maurizio

On 17/07/2022 04:28, Lost Illusion wrote:
> Hello,
> I'm currently using jextract in tandem with Kotlin/Native's ability to
> generate shared libraries and header files. It works nicely until you
> add a class to the Kotlin code which generates a struct and a function
> pointer (the initializer for the class) as a struct member, with both
> having the same name. Here's a minimal header file with the same
> problem.
> test.h:
> ```
> struct {
>      int (*Foo)();
> } Foo;
> ```
> While this is valid for a header file, jextract has a problem
> processing it. Using the latest jextract on the jdk18 branch, and
> using the following command: `jextract test.h`. I get bombarded with
> 11 errors about resolving symbols and a duplicate class. Seems to be
> because a static class for the struct Foo is generated and an
> interface for the method Foo is also generated. I'm new to the project
> and not sure what the correct behavior should be in order to fix this
> issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20220719/2e8d45db/attachment-0001.htm>

From mcimadamore at openjdk.org  Tue Jul 19 10:44:50 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 19 Jul 2022 10:44:50 GMT
Subject: Integrated: Remove spurious `^` char from tarball name
Message-ID: <GO8VVthM1nLlMWungcS_QMdTm0qF95re7RfF4gMk_gw=.d617b7d7-6446-4dec-bfb0-3ef8da778a56@github.com>

As the title says, this simple patch removes a spurious `^` char in the replacement text of a substitution applied during the tarball generation.
Because of that, on Linux, the generated tarball has a topdir named `^jextract-<version>`.

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

Commit messages:
 - Initial push

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

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

From sundar at openjdk.org  Tue Jul 19 10:44:50 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 19 Jul 2022 10:44:50 GMT
Subject: Integrated: Remove spurious `^` char from tarball name
In-Reply-To: <GO8VVthM1nLlMWungcS_QMdTm0qF95re7RfF4gMk_gw=.d617b7d7-6446-4dec-bfb0-3ef8da778a56@github.com>
References: <GO8VVthM1nLlMWungcS_QMdTm0qF95re7RfF4gMk_gw=.d617b7d7-6446-4dec-bfb0-3ef8da778a56@github.com>
Message-ID: <NmxEALkuoyU7_AnPl8tJ6JO11uXzG2a5U6_QRE1K4mQ=.2412829e-957c-4fb8-8bc4-5ebad746c635@github.com>

On Tue, 19 Jul 2022 10:36:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As the title says, this simple patch removes a spurious `^` char in the replacement text of a substitution applied during the tarball generation.
> Because of that, on Linux, the generated tarball has a topdir named `^jextract-<version>`.

LGTM

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

Marked as reviewed by sundar (Committer).

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

From mcimadamore at openjdk.org  Tue Jul 19 10:44:51 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 19 Jul 2022 10:44:51 GMT
Subject: Integrated: Remove spurious `^` char from tarball name
In-Reply-To: <GO8VVthM1nLlMWungcS_QMdTm0qF95re7RfF4gMk_gw=.d617b7d7-6446-4dec-bfb0-3ef8da778a56@github.com>
References: <GO8VVthM1nLlMWungcS_QMdTm0qF95re7RfF4gMk_gw=.d617b7d7-6446-4dec-bfb0-3ef8da778a56@github.com>
Message-ID: <qjDorFNi4zOjy-kZnUpO2cdrqwARPvavf326RB6X_8E=.f18d4d16-63fc-4de4-86c2-6c833fc2e4b4@github.com>

On Tue, 19 Jul 2022 10:36:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As the title says, this simple patch removes a spurious `^` char in the replacement text of a substitution applied during the tarball generation.
> Because of that, on Linux, the generated tarball has a topdir named `^jextract-<version>`.

This pull request has now been integrated.

Changeset: 33a0b0c8
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/33a0b0c857de8aa8dbc13a7b815a23ce31c5969c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

Remove spurious `^` char from tarball name

Reviewed-by: sundar

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

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

From sundar at openjdk.org  Tue Jul 19 10:44:59 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 19 Jul 2022 10:44:59 GMT
Subject: RFR: 7903237: pointer to function struct member with the same name as
 struct crashes jextract
Message-ID: <WhwnP-KUJ3joMKeNwQjormcwNJk5sXWimrfn59YSUnM=.8eaa1723-bd36-460a-8025-16d431321eb6@github.com>

The lower case name was (wrongly) used to check hierarchical clash as well. Should be used only for local peers.

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

Commit messages:
 - 7903237: pointer to function struct member with the same name as struct crashes jextract

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

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

From mcimadamore at openjdk.org  Tue Jul 19 11:16:21 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 19 Jul 2022 11:16:21 GMT
Subject: RFR: 7903237: pointer to function struct member with the same name
 as struct crashes jextract
In-Reply-To: <WhwnP-KUJ3joMKeNwQjormcwNJk5sXWimrfn59YSUnM=.8eaa1723-bd36-460a-8025-16d431321eb6@github.com>
References: <WhwnP-KUJ3joMKeNwQjormcwNJk5sXWimrfn59YSUnM=.8eaa1723-bd36-460a-8025-16d431321eb6@github.com>
Message-ID: <Ay4bCUQjMdyoGgIOXmq8RVPMvC-r89dks8LIWdn34Zs=.2bdc3bf6-c9cc-4d5a-8a7c-d8f13693dc44@github.com>

On Tue, 19 Jul 2022 10:38:11 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> The lower case name was (wrongly) used to check hierarchical clash as well. Should be used only for local peers.

Ugh - good catch!

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

Marked as reviewed by mcimadamore (Committer).

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

From sundar at openjdk.org  Tue Jul 19 11:28:15 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 19 Jul 2022 11:28:15 GMT
Subject: Integrated: 7903237: pointer to function struct member with the same
 name as struct crashes jextract
In-Reply-To: <WhwnP-KUJ3joMKeNwQjormcwNJk5sXWimrfn59YSUnM=.8eaa1723-bd36-460a-8025-16d431321eb6@github.com>
References: <WhwnP-KUJ3joMKeNwQjormcwNJk5sXWimrfn59YSUnM=.8eaa1723-bd36-460a-8025-16d431321eb6@github.com>
Message-ID: <tfEPKr31-XoipwnSLblzAqO-RFBi1A45n-rMFzu86og=.b09ac816-02af-4092-b375-afa61a7123e8@github.com>

On Tue, 19 Jul 2022 10:38:11 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> The lower case name was (wrongly) used to check hierarchical clash as well. Should be used only for local peers.

This pull request has now been integrated.

Changeset: 0582eaf1
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/0582eaf1b4cdba95f0ee8c2480767433bb647d0d
Stats:     52 lines in 3 files changed: 48 ins; 0 del; 4 mod

7903237: pointer to function struct member with the same name as struct crashes jextract

Reviewed-by: mcimadamore

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

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

From sundar at openjdk.org  Tue Jul 19 12:24:37 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 19 Jul 2022 12:24:37 GMT
Subject: RFR: backport of 7903237: pointer to function struct member with the
 same name as struct crashes jextract
Message-ID: <PIrysYvx8YuYdjxLDfhRhoKtBntE3_qejWZ4_i2or1A=.5a7c1ac3-c498-4595-a373-280e1898a3b1@github.com>

backport of 7903237: pointer to function struct member with the same name as struct crashes jextract

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

Commit messages:
 - backport of 7903237: pointer to function struct member with the same name as struct crashes jextract

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

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

From mcimadamore at openjdk.org  Tue Jul 19 12:24:37 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 19 Jul 2022 12:24:37 GMT
Subject: RFR: backport of 7903237: pointer to function struct member with
 the same name as struct crashes jextract
In-Reply-To: <PIrysYvx8YuYdjxLDfhRhoKtBntE3_qejWZ4_i2or1A=.5a7c1ac3-c498-4595-a373-280e1898a3b1@github.com>
References: <PIrysYvx8YuYdjxLDfhRhoKtBntE3_qejWZ4_i2or1A=.5a7c1ac3-c498-4595-a373-280e1898a3b1@github.com>
Message-ID: <Mp7B2KYHFjs07_km4E5Hjd_9Ix4WAwdgwxpkaXOpPxQ=.04df3998-19e8-4846-84dd-8fcd655d1c1d@github.com>

On Tue, 19 Jul 2022 12:19:12 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> backport of 7903237: pointer to function struct member with the same name as struct crashes jextract

Looks good

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

Marked as reviewed by mcimadamore (Committer).

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

From sundar at openjdk.org  Tue Jul 19 12:29:26 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Tue, 19 Jul 2022 12:29:26 GMT
Subject: Integrated: backport of 7903237: pointer to function struct member
 with the same name as struct crashes jextract
In-Reply-To: <PIrysYvx8YuYdjxLDfhRhoKtBntE3_qejWZ4_i2or1A=.5a7c1ac3-c498-4595-a373-280e1898a3b1@github.com>
References: <PIrysYvx8YuYdjxLDfhRhoKtBntE3_qejWZ4_i2or1A=.5a7c1ac3-c498-4595-a373-280e1898a3b1@github.com>
Message-ID: <D-e7rcnznd2zdtuA8gaMyQX1UD9CKfcrl4ef1l73qTQ=.db3e5de5-de15-4447-aca5-c5f2d1cfc338@github.com>

On Tue, 19 Jul 2022 12:19:12 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> backport of 7903237: pointer to function struct member with the same name as struct crashes jextract

This pull request has now been integrated.

Changeset: 1c72e46b
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/1c72e46b15160a8482cd3d013800dbaeff1e83df
Stats:     52 lines in 3 files changed: 48 ins; 0 del; 4 mod

backport of 7903237: pointer to function struct member with the same name as struct crashes jextract

Reviewed-by: mcimadamore

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

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

From maurizio.cimadamore at oracle.com  Tue Jul 26 14:14:57 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 26 Jul 2022 15:14:57 +0100
Subject: Jextract binaries now live!
Message-ID: <42c99841-4be7-b2fc-1a43-4f6e785fb6f0@oracle.com>

Hi,
We're pleased to announce that the jextract binaries obtained from the 
standalone repo are available here:

https://jdk.java.net/jextract/

It took quite a lot of effort to separate the jextract component from 
the panama repo, and I'd like to thank everyone involved in the process.

Note: the build covers the Java 19 version of jextract. If you need a 
version of jextract that works with Java 18, you can either build the 
standalone jextract, using the Java 18 branch [1], or download the 
panama repo + jextract [2].

Maurizio

[1] - https://github.com/openjdk/jextract/tree/jdk18
[2] - https://jdk.java.net/panama/



From im at lostillusion.net  Thu Jul 28 00:00:31 2022
From: im at lostillusion.net (Marko)
Date: Wed, 27 Jul 2022 20:00:31 -0400
Subject: BUG: function pointers inside a struct do not generate
 SegmentAllocators when needed
Message-ID: <CAHFdwNboGw===xxZ3_3czsi7sf=SHqBsWNEq0nSsj-rzMtUGkA@mail.gmail.com>

Hello again!
When trying to call a function pointer inside a struct which returns a
MemorySegment, I receive the following error:
```
Exception in thread "main" java.lang.AssertionError: should not reach here
at Foo$bar.lambda$ofAddress$0(Foo.java:34)
at Main.main(Main.java:8)
Caused by: java.lang.invoke.WrongMethodTypeException: expected
(NativeSymbol,SegmentAllocator)MemorySegment but found
(NativeSymbol)MemorySegment
at java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:523)
at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:532)
at Foo$bar.lambda$ofAddress$0(Foo.java:32)
... 1 more
```
I believe this is due to
`FunctionalInterfaceBuilder#emitFunctionalFactoryForPointer` not
checking to see if the returnType is a MemorySegment, as it does in
`HeaderFileBuilder` for regular functions, see
https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java#L122-L127.

I began implementing a fix by copying this functionality over, however
there is a bit of an issue I came across. When jextract emits the
getter for the functional interface in a struct (StructBuilder), only
the name of the interface is known. AFAIK, it does not know whether it
needs a SegmentAllocator and cannot currently generate the correct
code.

I thought about adding another field to the method
`emitFunctionalFactoryForPointer`, similar to fiName, like a boolean
for whether a segment allocator is needed or not, however, I can't help but
feel it is a bit hacky. I wonder what your opinions are on this.

A repro can be found here:
https://github.com/lost-illusi0n/jextract-func-ptr-seg-alloc-repro
Just run the run script if you are on Linux. You will have to change the
library output in the script if you are on another os.

From sundar at openjdk.org  Thu Jul 28 09:58:53 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 28 Jul 2022 09:58:53 GMT
Subject: Integrated: Remove spurious ^ char from tarball name
Message-ID: <R6mR1GNjCuKaveaBFC0pAXU78Y4eXGXr3Y2yZ-zwdnQ=.6c98182c-2c88-4f3f-8ca2-e338edd1db69@github.com>

backporting the same fix from jdk19

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

Commit messages:
 - Remove spurious ^ char from tarball name

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

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

From mcimadamore at openjdk.org  Thu Jul 28 09:58:54 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Jul 2022 09:58:54 GMT
Subject: Integrated: Remove spurious ^ char from tarball name
In-Reply-To: <R6mR1GNjCuKaveaBFC0pAXU78Y4eXGXr3Y2yZ-zwdnQ=.6c98182c-2c88-4f3f-8ca2-e338edd1db69@github.com>
References: <R6mR1GNjCuKaveaBFC0pAXU78Y4eXGXr3Y2yZ-zwdnQ=.6c98182c-2c88-4f3f-8ca2-e338edd1db69@github.com>
Message-ID: <S9icxu0c34q7utCYEj6VyTlgr3ostnrruIq-8uUgJ80=.9ff3eaa5-774c-4d5d-a174-376effe8b37e@github.com>

On Thu, 28 Jul 2022 09:50:02 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> backporting the same fix from jdk19

Looks good

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

Marked as reviewed by mcimadamore (Committer).

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

From sundar at openjdk.org  Thu Jul 28 09:58:54 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 28 Jul 2022 09:58:54 GMT
Subject: Integrated: Remove spurious ^ char from tarball name
In-Reply-To: <R6mR1GNjCuKaveaBFC0pAXU78Y4eXGXr3Y2yZ-zwdnQ=.6c98182c-2c88-4f3f-8ca2-e338edd1db69@github.com>
References: <R6mR1GNjCuKaveaBFC0pAXU78Y4eXGXr3Y2yZ-zwdnQ=.6c98182c-2c88-4f3f-8ca2-e338edd1db69@github.com>
Message-ID: <bdvrQvNA6DVxNmDhssI2xmPij71spq4h-sN7lnBn0xQ=.b516d21b-40a4-4468-a1d5-dfc6868ae479@github.com>

On Thu, 28 Jul 2022 09:50:02 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> backporting the same fix from jdk19

This pull request has now been integrated.

Changeset: a1701b67
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/a1701b677e3921ba6b555c18bc2d4322ec0e6829
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

Remove spurious ^ char from tarball name

Reviewed-by: mcimadamore

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

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

From jorn.vernee at oracle.com  Thu Jul 28 21:20:18 2022
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Thu, 28 Jul 2022 23:20:18 +0200
Subject: BUG: function pointers inside a struct do not generate
 SegmentAllocators when needed
In-Reply-To: <CAHFdwNboGw===xxZ3_3czsi7sf=SHqBsWNEq0nSsj-rzMtUGkA@mail.gmail.com>
References: <CAHFdwNboGw===xxZ3_3czsi7sf=SHqBsWNEq0nSsj-rzMtUGkA@mail.gmail.com>
Message-ID: <18e2cc45-c1fc-4ff7-4aa1-2fad60d40187@oracle.com>

Hello Marko,

Thanks for the report! I can reproduce it here as well. I think the 
problem is the lambda in the `ofAddress` factory that is generated in 
the interface for the callback type. Note that the getter will just end 
up calling that factory. (you can see that also in your stack trace: `at 
Foo$bar.lambda$ofAddress$0(Foo.java:32)`).

I've filed: https://bugs.openjdk.org/browse/CODETOOLS-7903239

Cheers,
Jorn

On 28/07/2022 02:00, Marko wrote:
> Hello again!
> When trying to call a function pointer inside a struct which returns a
> MemorySegment, I receive the following error:
> ```
> Exception in thread "main" java.lang.AssertionError: should not reach here
> at Foo$bar.lambda$ofAddress$0(Foo.java:34)
> at Main.main(Main.java:8)
> Caused by: java.lang.invoke.WrongMethodTypeException: expected
> (NativeSymbol,SegmentAllocator)MemorySegment but found
> (NativeSymbol)MemorySegment
> at java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:523)
> at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:532)
> at Foo$bar.lambda$ofAddress$0(Foo.java:32)
> ... 1 more
> ```
> I believe this is due to
> `FunctionalInterfaceBuilder#emitFunctionalFactoryForPointer` not
> checking to see if the returnType is a MemorySegment, as it does in
> `HeaderFileBuilder` for regular functions, see
> https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java#L122-L127.
>
> I began implementing a fix by copying this functionality over, however
> there is a bit of an issue I came across. When jextract emits the
> getter for the functional interface in a struct (StructBuilder), only
> the name of the interface is known. AFAIK, it does not know whether it
> needs a SegmentAllocator and cannot currently generate the correct
> code.
>
> I thought about adding another field to the method
> `emitFunctionalFactoryForPointer`, similar to fiName, like a boolean
> for whether a segment allocator is needed or not, however, I can't help but
> feel it is a bit hacky. I wonder what your opinions are on this.
>
> A repro can be found here:
> https://github.com/lost-illusi0n/jextract-func-ptr-seg-alloc-repro
> Just run the run script if you are on Linux. You will have to change the
> library output in the script if you are on another os.

From im at lostillusion.net  Thu Jul 28 23:25:08 2022
From: im at lostillusion.net (Marko)
Date: Thu, 28 Jul 2022 19:25:08 -0400
Subject: BUG: function pointers inside a struct do not generate
 SegmentAllocators when needed
In-Reply-To: <18e2cc45-c1fc-4ff7-4aa1-2fad60d40187@oracle.com>
References: <CAHFdwNboGw===xxZ3_3czsi7sf=SHqBsWNEq0nSsj-rzMtUGkA@mail.gmail.com>
 <18e2cc45-c1fc-4ff7-4aa1-2fad60d40187@oracle.com>
Message-ID: <CAHFdwNb0O6nwu_ajLHy9VfTrv4OdfvJqWFZ5LqTd7MB03WXAQQ@mail.gmail.com>

My apologies, gmail seems to have only replied directly to Jorn
previously. Here is the original message.

Hey Jorn,
Thanks for filing the report. I agree that the problem is where the
`ofAddress` function is generated. It does not check to see if a
segment allocator is needed. It seems quite trivial to add though as
it is already implemented for regular functions,
https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java#L122-L127.

However, when this is fixed, the getter must also be updated to
reflect the addition of the SegmentAllocator parameter.
I believe this constitutes an additional parameter here
https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/StructBuilder.java#L128=
similar to fiName, that represents whether a segment allocator is
needed or not. It seems a bit odd though IMHO, as then
HeaderFileBuilder#addVar and ToplevelBuilder#addVar are also forced to
have this parameter even though it goes unused there.

I implemented the fix and the proper getter generation as well, and it
seems to all work on my end. I wonder if this boolean parameter is the
way to go before submitting a PR though.

Thanks,
Marko

On Thu, Jul 28, 2022 at 5:20 PM Jorn Vernee <jorn.vernee at oracle.com> wrote:
>
> Hello Marko,
>
> Thanks for the report! I can reproduce it here as well. I think the
> problem is the lambda in the `ofAddress` factory that is generated in
> the interface for the callback type. Note that the getter will just end
> up calling that factory. (you can see that also in your stack trace: `at
> Foo$bar.lambda$ofAddress$0(Foo.java:32)`).
>
> I've filed: https://bugs.openjdk.org/browse/CODETOOLS-7903239
>
> Cheers,
> Jorn
>
> On 28/07/2022 02:00, Marko wrote:
> > Hello again!
> > When trying to call a function pointer inside a struct which returns a
> > MemorySegment, I receive the following error:
> > ```
> > Exception in thread "main" java.lang.AssertionError: should not reach here
> > at Foo$bar.lambda$ofAddress$0(Foo.java:34)
> > at Main.main(Main.java:8)
> > Caused by: java.lang.invoke.WrongMethodTypeException: expected
> > (NativeSymbol,SegmentAllocator)MemorySegment but found
> > (NativeSymbol)MemorySegment
> > at java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:523)
> > at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:532)
> > at Foo$bar.lambda$ofAddress$0(Foo.java:32)
> > ... 1 more
> > ```
> > I believe this is due to
> > `FunctionalInterfaceBuilder#emitFunctionalFactoryForPointer` not
> > checking to see if the returnType is a MemorySegment, as it does in
> > `HeaderFileBuilder` for regular functions, see
> > https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java#L122-L127.
> >
> > I began implementing a fix by copying this functionality over, however
> > there is a bit of an issue I came across. When jextract emits the
> > getter for the functional interface in a struct (StructBuilder), only
> > the name of the interface is known. AFAIK, it does not know whether it
> > needs a SegmentAllocator and cannot currently generate the correct
> > code.
> >
> > I thought about adding another field to the method
> > `emitFunctionalFactoryForPointer`, similar to fiName, like a boolean
> > for whether a segment allocator is needed or not, however, I can't help but
> > feel it is a bit hacky. I wonder what your opinions are on this.
> >
> > A repro can be found here:
> > https://github.com/lost-illusi0n/jextract-func-ptr-seg-alloc-repro
> > Just run the run script if you are on Linux. You will have to change the
> > library output in the script if you are on another os.

From im at lostillusion.net  Thu Jul 28 23:42:23 2022
From: im at lostillusion.net (Marko)
Date: Thu, 28 Jul 2022 19:42:23 -0400
Subject: BUG: function pointers inside a struct do not generate
 SegmentAllocators when needed
In-Reply-To: <CAHFdwNb0O6nwu_ajLHy9VfTrv4OdfvJqWFZ5LqTd7MB03WXAQQ@mail.gmail.com>
References: <CAHFdwNboGw===xxZ3_3czsi7sf=SHqBsWNEq0nSsj-rzMtUGkA@mail.gmail.com>
 <18e2cc45-c1fc-4ff7-4aa1-2fad60d40187@oracle.com>
 <CAHFdwNb0O6nwu_ajLHy9VfTrv4OdfvJqWFZ5LqTd7MB03WXAQQ@mail.gmail.com>
Message-ID: <CAHFdwNaVTWJdqkf=bidiJN-iQeyyi8vyF0Xe__bOeP0Q9Ncx8g@mail.gmail.com>

Perhaps the additional parameter was not as weird as I originally thought.
> It seems a bit odd though IMHO, as then
> HeaderFileBuilder#addVar and ToplevelBuilder#addVar are also forced to
> have this parameter even though it goes unused there.

I just tried it out and the getters are also missing when generated as
a part of the header file.
I'll polish my fix and send a PR for a better opinion.

Thanks
Marko


On Thu, Jul 28, 2022 at 7:25 PM Marko <im at lostillusion.net> wrote:
>
> My apologies, gmail seems to have only replied directly to Jorn
> previously. Here is the original message.
>
> Hey Jorn,
> Thanks for filing the report. I agree that the problem is where the
> `ofAddress` function is generated. It does not check to see if a
> segment allocator is needed. It seems quite trivial to add though as
> it is already implemented for regular functions,
> https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java#L122-L127.
>
> However, when this is fixed, the getter must also be updated to
> reflect the addition of the SegmentAllocator parameter.
> I believe this constitutes an additional parameter here
> https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/StructBuilder.java#L128=
> similar to fiName, that represents whether a segment allocator is
> needed or not. It seems a bit odd though IMHO, as then
> HeaderFileBuilder#addVar and ToplevelBuilder#addVar are also forced to
> have this parameter even though it goes unused there.
>
> I implemented the fix and the proper getter generation as well, and it
> seems to all work on my end. I wonder if this boolean parameter is the
> way to go before submitting a PR though.
>
> Thanks,
> Marko
>
> On Thu, Jul 28, 2022 at 5:20 PM Jorn Vernee <jorn.vernee at oracle.com> wrote:
> >
> > Hello Marko,
> >
> > Thanks for the report! I can reproduce it here as well. I think the
> > problem is the lambda in the `ofAddress` factory that is generated in
> > the interface for the callback type. Note that the getter will just end
> > up calling that factory. (you can see that also in your stack trace: `at
> > Foo$bar.lambda$ofAddress$0(Foo.java:32)`).
> >
> > I've filed: https://bugs.openjdk.org/browse/CODETOOLS-7903239
> >
> > Cheers,
> > Jorn
> >
> > On 28/07/2022 02:00, Marko wrote:
> > > Hello again!
> > > When trying to call a function pointer inside a struct which returns a
> > > MemorySegment, I receive the following error:
> > > ```
> > > Exception in thread "main" java.lang.AssertionError: should not reach here
> > > at Foo$bar.lambda$ofAddress$0(Foo.java:34)
> > > at Main.main(Main.java:8)
> > > Caused by: java.lang.invoke.WrongMethodTypeException: expected
> > > (NativeSymbol,SegmentAllocator)MemorySegment but found
> > > (NativeSymbol)MemorySegment
> > > at java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:523)
> > > at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:532)
> > > at Foo$bar.lambda$ofAddress$0(Foo.java:32)
> > > ... 1 more
> > > ```
> > > I believe this is due to
> > > `FunctionalInterfaceBuilder#emitFunctionalFactoryForPointer` not
> > > checking to see if the returnType is a MemorySegment, as it does in
> > > `HeaderFileBuilder` for regular functions, see
> > > https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java#L122-L127.
> > >
> > > I began implementing a fix by copying this functionality over, however
> > > there is a bit of an issue I came across. When jextract emits the
> > > getter for the functional interface in a struct (StructBuilder), only
> > > the name of the interface is known. AFAIK, it does not know whether it
> > > needs a SegmentAllocator and cannot currently generate the correct
> > > code.
> > >
> > > I thought about adding another field to the method
> > > `emitFunctionalFactoryForPointer`, similar to fiName, like a boolean
> > > for whether a segment allocator is needed or not, however, I can't help but
> > > feel it is a bit hacky. I wonder what your opinions are on this.
> > >
> > > A repro can be found here:
> > > https://github.com/lost-illusi0n/jextract-func-ptr-seg-alloc-repro
> > > Just run the run script if you are on Linux. You will have to change the
> > > library output in the script if you are on another os.

From maurizio.cimadamore at oracle.com  Fri Jul 29 21:40:55 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 29 Jul 2022 22:40:55 +0100
Subject: BUG: function pointers inside a struct do not generate
 SegmentAllocators when needed
In-Reply-To: <CAHFdwNaVTWJdqkf=bidiJN-iQeyyi8vyF0Xe__bOeP0Q9Ncx8g@mail.gmail.com>
References: <CAHFdwNboGw===xxZ3_3czsi7sf=SHqBsWNEq0nSsj-rzMtUGkA@mail.gmail.com>
 <18e2cc45-c1fc-4ff7-4aa1-2fad60d40187@oracle.com>
 <CAHFdwNb0O6nwu_ajLHy9VfTrv4OdfvJqWFZ5LqTd7MB03WXAQQ@mail.gmail.com>
 <CAHFdwNaVTWJdqkf=bidiJN-iQeyyi8vyF0Xe__bOeP0Q9Ncx8g@mail.gmail.com>
Message-ID: <f3de9911-5014-8bde-52b1-cc36428b9134@oracle.com>

Hi Marko,
I think adding the missing SegmentAllocator parameter can be possible 
fix, but the reality here is that there is an asymmetry between two use 
cases:

1. when you create an upcall from a lambda expression, the segment 
allocator parameter is not required (in fact the upcall machinery will 
_not_ provide one to the upcall, see below)
2. when you want to wrap a functional interface around an upcall stub 
address, the struct returned by the stub will be copied into a _fresh_ 
segment allocated using the provided segment allocator

Because of this, I think that just prepending a SegmentAllocator 
parameter in front of the functional descriptor is not gonna cut it. 
That is, if you have a C function pointer like:

```
struct Foo (*f)(int)
```

The Linker will expect an upcall MethodHandle with signature 
`(int)MemorySegment`, and no SegmentAllocator parameter. If you add an 
extra SegmentAllocator parameter, then the method handle we derive from 
the lambda expression in (1) is going to have the wrong type (unless we 
insert a dummy SegmentAllocator argument).

When chatting with Jorn offline about this, we were discussing the 
possibility of emitting, for the above signature, a functional interface 
like the one below:

```
interface FI$f {

 ?? MemorySegment apply(int i);
 ?? default MemorySegment(SegmentAllocator allocator, int i) { throw new 
UnsupportedOperationException(); }

 ?? ...
}
```

This has some advantages:

* we can still provide a lambda-friendly factory for (1) - note that the 
functional interface signature would still be the "correct" one for the 
upcall (e.g. the one w/o the SegmentAllocator), so nothing changes here
* we can also provide the `ofAddress` method for (2), which builds a new 
FI$f given a memory address; to do that, we create an instance as follows:

```
FI$f ofAddress(MemoryAddress address) {
 ?? ...

 ?? return new FI$f() {
 ????? MemorySegment apply(int i) { return 
apply(SegmentAllocator.implicitAllocator(), i); }
 ????? MemorySegment apply(SegmentAllocator, int i) { <call downcall 
handle> }
 ?? };
}
```

in other words, the returned functional interface instance supports two 
invocation modes, w/ and w/o a SegmentAllocator. If no SegmentAllocator 
is provided, we just use the implicit allocator (another option would be 
to throw, but perhaps that would be too harsh?)

Thoughts?

Cheers
Maurizio






On 29/07/2022 00:42, Marko wrote:
> Perhaps the additional parameter was not as weird as I originally thought.
>> It seems a bit odd though IMHO, as then
>> HeaderFileBuilder#addVar and ToplevelBuilder#addVar are also forced to
>> have this parameter even though it goes unused there.
> I just tried it out and the getters are also missing when generated as
> a part of the header file.
> I'll polish my fix and send a PR for a better opinion.
>
> Thanks
> Marko
>
>
> On Thu, Jul 28, 2022 at 7:25 PM Marko <im at lostillusion.net> wrote:
>> My apologies, gmail seems to have only replied directly to Jorn
>> previously. Here is the original message.
>>
>> Hey Jorn,
>> Thanks for filing the report. I agree that the problem is where the
>> `ofAddress` function is generated. It does not check to see if a
>> segment allocator is needed. It seems quite trivial to add though as
>> it is already implemented for regular functions,
>> https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java#L122-L127.
>>
>> However, when this is fixed, the getter must also be updated to
>> reflect the addition of the SegmentAllocator parameter.
>> I believe this constitutes an additional parameter here
>> https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/StructBuilder.java#L128=
>> similar to fiName, that represents whether a segment allocator is
>> needed or not. It seems a bit odd though IMHO, as then
>> HeaderFileBuilder#addVar and ToplevelBuilder#addVar are also forced to
>> have this parameter even though it goes unused there.
>>
>> I implemented the fix and the proper getter generation as well, and it
>> seems to all work on my end. I wonder if this boolean parameter is the
>> way to go before submitting a PR though.
>>
>> Thanks,
>> Marko
>>
>> On Thu, Jul 28, 2022 at 5:20 PM Jorn Vernee <jorn.vernee at oracle.com> wrote:
>>> Hello Marko,
>>>
>>> Thanks for the report! I can reproduce it here as well. I think the
>>> problem is the lambda in the `ofAddress` factory that is generated in
>>> the interface for the callback type. Note that the getter will just end
>>> up calling that factory. (you can see that also in your stack trace: `at
>>> Foo$bar.lambda$ofAddress$0(Foo.java:32)`).
>>>
>>> I've filed: https://bugs.openjdk.org/browse/CODETOOLS-7903239
>>>
>>> Cheers,
>>> Jorn
>>>
>>> On 28/07/2022 02:00, Marko wrote:
>>>> Hello again!
>>>> When trying to call a function pointer inside a struct which returns a
>>>> MemorySegment, I receive the following error:
>>>> ```
>>>> Exception in thread "main" java.lang.AssertionError: should not reach here
>>>> at Foo$bar.lambda$ofAddress$0(Foo.java:34)
>>>> at Main.main(Main.java:8)
>>>> Caused by: java.lang.invoke.WrongMethodTypeException: expected
>>>> (NativeSymbol,SegmentAllocator)MemorySegment but found
>>>> (NativeSymbol)MemorySegment
>>>> at java.base/java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:523)
>>>> at java.base/java.lang.invoke.Invokers.checkExactType(Invokers.java:532)
>>>> at Foo$bar.lambda$ofAddress$0(Foo.java:32)
>>>> ... 1 more
>>>> ```
>>>> I believe this is due to
>>>> `FunctionalInterfaceBuilder#emitFunctionalFactoryForPointer` not
>>>> checking to see if the returnType is a MemorySegment, as it does in
>>>> `HeaderFileBuilder` for regular functions, see
>>>> https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java#L122-L127.
>>>>
>>>> I began implementing a fix by copying this functionality over, however
>>>> there is a bit of an issue I came across. When jextract emits the
>>>> getter for the functional interface in a struct (StructBuilder), only
>>>> the name of the interface is known. AFAIK, it does not know whether it
>>>> needs a SegmentAllocator and cannot currently generate the correct
>>>> code.
>>>>
>>>> I thought about adding another field to the method
>>>> `emitFunctionalFactoryForPointer`, similar to fiName, like a boolean
>>>> for whether a segment allocator is needed or not, however, I can't help but
>>>> feel it is a bit hacky. I wonder what your opinions are on this.
>>>>
>>>> A repro can be found here:
>>>> https://github.com/lost-illusi0n/jextract-func-ptr-seg-alloc-repro
>>>> Just run the run script if you are on Linux. You will have to change the
>>>> library output in the script if you are on another os.

From duke at openjdk.org  Sat Jul 30 11:02:22 2022
From: duke at openjdk.org (Marko)
Date: Sat, 30 Jul 2022 11:02:22 GMT
Subject: RFR: 7903239: ofAddress factory of function pointer type is wrong for
 struct returns
Message-ID: <VOQBzvWupTMIQsAccTVhA-t5RFqY36XSmpTRgqbYTnY=.ec8ee007-22ae-41bb-abbe-eeb291c899a0@github.com>

When generating the lambda inside the `ofAddress` factory, it is missing the `SegmentAllocator` needed when the function returns a struct. This is [implemented for regular functions](https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2480767433bb647d0d/src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java#L122-L127), but not for function pointers.

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

Commit messages:
 - 7903239: ofAddress factory of function pointer type is wrong for struct returns

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

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