RFR: 8288130: compiler error with AP and explicit record accessor

[Vicente Romero]

Please review this PR which is fixing a tricky bug in records. Right now this code is trivial to compile by javac:

record TestRecord<T>(T someValue) {
    public T someValue() {
        return this.someValue;
    }
}

but in the presence of an annotation processor this code is entered at least two times. Every one of those times a new type variable is created. Now for records this have some implications. Record components are created once, in most cases unless there is an error for example, meaning that the type of the record component in this case was not in sync with the type of the accessor, and this is a mismatch reported as an error by the compiler. Note that if the accessor was not explicitly declared but generated this wouldn't happen as the accessor is generated from the info in the record component so a generated accessor is always in sync with its corresponding record component.

A possible solution to this issue could be to recreate the record component if there is at least a type variable in its type. But I decided to go for an all in solution recreating the record component always so if there are annotation processor rounds, a new record component would be created for each of them. This way we can future-proof this area of records which has seen bugs in the past and be sure that we are always dealing with a fresh instance of the record components.

TIA

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

Commit messages:
 - adding accompanying regression test
 - 8288130: compiler error with AP and explicit record accessor

Changes: https://git.openjdk.org/jdk/pull/9160/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9160&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288130
  Stats: 283 lines in 4 files changed: 104 ins; 79 del; 100 mod
  Patch: https://git.openjdk.org/jdk/pull/9160.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9160/head:pull/9160

PR: https://git.openjdk.org/jdk/pull/9160