7903984: Inline upcallHandle method to reduce shared code across multiple generations

[nizarbenalla]

Please review this patch to inline the upcallHandle method, reducing the amount of shared items across multiple jextract generations.

Edit: all tests pass in CI, GitHub failure is unrelated

TIA

---

Progress

• Change must not contain extraneous whitespace
• Change must be properly reviewed (no review required)

Issue

• CODETOOLS-7903984: Inline upcallHandle method to reduce shared code across multiple generations (Enhancement - P4)

Reviewers

• Maurizio Cimadamore (@mcimadamore - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jextract.git pull/279/head:pull/279
$ git checkout pull/279

Update a local copy of the PR:
$ git checkout pull/279
$ git pull https://git.openjdk.org/jextract.git pull/279/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 279

View PR using the GUI difftool:
$ git pr show -t 279

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jextract/pull/279.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back nbenalla! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@nizarbenalla This change now passes all automated pre-integration checks.

After integration, the commit message for the final commit will be:

7903984: Inline upcallHandle method to reduce shared code across multiple generations

Reviewed-by: mcimadamore

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@mcimadamore) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[mlbridge]

Webrevs

• 00: Full (3d387faf)

[mcimadamore]

Looks good. Let's also hear from @JornVernee

(when looking at some generated code I also noted that the functional interface code already has a try/catch block in the invoke method).

I guess the unfortunate issue here is that the use is from a static initializer - which means we either need to put the logic in a method (as you have done) or use a static initializer. So we pay a bit more than just for the single try/catch block.

One thing I noticed is that ConstantBootstraps has bootstraps to make field var handles (static and non-static) as well as array element var handles. I wonder if we should double down on those and add a way to create direct method handles too... these methods don't throw checked exception, so they are more amenable to generated code like this.