8292159: TYPE_USE annotations on generic type arguments of record components discarded

[sadayapalam]

Handle carryover of type annotations to record components in a place which will be
reached regardless of whether there are any annotations in a SE5 annotation location.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change requires a CSR request to be approved

Issues

• JDK-8292159: TYPE_USE annotations on generic type arguments of record components discarded
• JDK-8295705: TYPE_USE annotations on generic type arguments of record components discarded (CSR)

Reviewers

• Vicente Romero (@vicente-romero-oracle - Reviewer) ⚠️ Review applies to 1f9085e6

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 10741

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10741.diff

[bridgekeeper]

👋 Welcome back sadayapalam! 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]

@sadayapalam The following label will be automatically applied to this pull request:

• compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 05: Full - Incremental (6734bd61)
• 04: Full - Incremental (4b82002a)
• 03: Full - Incremental (1f9085e6)
• 02: Full - Incremental (231f7401)
• 01: Full - Incremental (46378d32)
• 00: Full (21c91fc3)

[vicente-romero-oracle]

/csr needed

[openjdk]

@vicente-romero-oracle has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@sadayapalam please create a CSR request for issue JDK-8292159 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

[vicente-romero-oracle]

for completeness I think that the test should be executed with and without annotation processor

[jddarcy]

/csr needed

I agree it is reasonable to have a CSR to note the behavioral change; thanks,

[sadayapalam]

For the record(sic!) , javac's implementation seems to use terminology that differs from JLS (but still may be producing fully equivalent implementation)

See that JLS 8.10.1 says:

The record components of a record class, if any, are specified in the header of a
record declaration. Each record component consists of a type (optionally preceded
by one or more annotations) and an identifier that specifies the name of the
record component. A record component corresponds to two members of the record
class: a private field declared implicitly, and a public accessor method declared
explicitly or implicitly (§8.10.3).

Javac implementation treats the declaration in the record header as a component field
and generates record component from that.

In doing so, it is aligning with terminology used by JDK, which treats the components of
the record attribute as Record components.

The following is from Class.java

/*
     * Returns an array containing the components of the Record attribute,
     * or null if the attribute is not present.
     *
     * Note that this method returns non-null array on a class with
     * the Record attribute even if this class is not a record.
     */
    private native RecordComponent[] getRecordComponents0();

This may be just splitting hairs - but at least initially it is a bit confusing that we go from components fields to record components in javac implementation rather than vice versa.

As called out before, the net effect may be that a totally equivalent implementation results.

[vicente-romero-oracle]

looks good

[openjdk]

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

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

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

8292159: TYPE_USE annotations on generic type arguments of record components discarded

Reviewed-by: vromero

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 1 new commit pushed to the master branch:

• 210fe49: 6244831: JFileChooser does not have tooltip for Desktop, Recent etc ToggleButton on Windows Look and feel

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[sadayapalam]

/integrate

[openjdk]

Going to push as commit 4d9a1cd.
Since your change was applied there has been 1 commit pushed to the master branch:

• 210fe49: 6244831: JFileChooser does not have tooltip for Desktop, Recent etc ToggleButton on Windows Look and feel

Your commit was automatically rebased without conflicts.

[openjdk]

@sadayapalam Pushed as commit 4d9a1cd.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.