JDK 14 RFR of JDK-8224630: ElementScannerN, N > 9 should scan type parameters

[Erik Joelsson]

On 2019-12-04 19:29, Joe Darcy wrote:
> Hello,
>
> First on the build front, the -source/-target used in the bootstrap 
> build of langtools was stuck at 9; in the change I'm proposing to 
> update it to 13, the minimum boot JDK:
>
> --- old/make/autoconf/boot-jdk.m4    2019-12-04 19:16:42.209000999 -0800
> +++ new/make/autoconf/boot-jdk.m4    2019-12-04 19:16:41.925000999 -0800
> @@ -345,7 +345,7 @@
>
>    # When compiling code to be executed by the Boot JDK, force 
> compatibility with the
>    # oldest supported bootjdk.
> -  BOOT_JDK_SOURCETARGET="-source 9 -target 9"
> +  BOOT_JDK_SOURCETARGET="-source 13 -target 13"
>    AC_SUBST(BOOT_JDK_SOURCETARGET)
>
I had missed this configuration. Ideally I want all the versions that 
need updating for each new release collected into the version-numbers 
file, or even better, be derived from existing numbers in there. Would 
it be ok to just derive this number from the list of valid bootjdk versions?

/Erik

> AC_SUBST(JAVAC_FLAGS)
>
> This should get added to the list of files updated when the boot JDK 
> is revved.
>
> On the javax.lang.model front, with the changes for records pushed 
> into JDK 14 there is now a ElementScanner14 class and I think it is 
> time to address
>
>     JDK-8224630: ElementScannerN, N > 9 should scan type parameters
>     http://cr.openjdk.java.net/~darcy/8224630.0/
>     CSR: https://bugs.openjdk.java.net/browse/JDK-8235371
>
> As the bug title implies, the existing scanner classes don't touch 
> type parameters, which is arguably a bug. The scanners mostly touch 
> enclosed elements, but they do also touch method/constructor 
> parameters which are not considered to be enclosed elements.
>
> In its current form, the webrev relies on the test previously added 
> for RoundEnvironment. However, I acknowledge it would be possible to 
> add tests for this particular change.
>
> Thanks,
>
> -Joe
>