From jwilhelm at openjdk.java.net Thu Jul 1 00:17:39 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 1 Jul 2021 00:17:39 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8262841: Clarify the behavior of PhantomReference::refersTo - 8269703: ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on Windows-X64 with -Xcomp - 8269513: Clarify the spec wrt `useOldISOCodes` system property - 8268897: [TESTBUG] compiler/compilercontrol/mixed/RandomCommandsTest.java must not fail on Command.quiet - 8268557: Module page uses unstyled table class - 8269691: ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64 - 8269486: CallerAccessTest fails for non server variant - 8269614: [s390] Interpreter checks wrong bit for slow path instance allocation - 8269594: assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark - ... and 6 more: https://git.openjdk.java.net/jdk/compare/85262c71...d9b654b1 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4645&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4645&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4645/files Stats: 394 lines in 29 files changed: 280 ins; 26 del; 88 mod Patch: https://git.openjdk.java.net/jdk/pull/4645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4645/head:pull/4645 PR: https://git.openjdk.java.net/jdk/pull/4645 From cushon at openjdk.java.net Thu Jul 1 00:20:04 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Thu, 1 Jul 2021 00:20:04 GMT Subject: [jdk17] Integrated: 8268592: JDK-8262891 causes an NPE in Lint.augment In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 22:40:50 GMT, Liam Miller-Cushon wrote: > 8268592: JDK-8262891 causes an NPE in Lint.augment This pull request has now been integrated. Changeset: 4930ae96 Author: Liam Miller-Cushon URL: https://git.openjdk.java.net/jdk17/commit/4930ae96d8083070482f6ac78faed9ae9dda2df7 Stats: 63 lines in 2 files changed: 63 ins; 0 del; 0 mod 8268592: JDK-8262891 causes an NPE in Lint.augment Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk17/pull/188 From jwilhelm at openjdk.java.net Thu Jul 1 01:06:45 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 1 Jul 2021 01:06:45 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 125 commits: - Merge - 8268637: Update --release 17 symbol information for JDK 17 build 28 Reviewed-by: iris - 8269678: Remove unimplemented and unused os::bind_to_processor() Reviewed-by: dcubed - 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML Reviewed-by: lancea, naoto, iris, joehw - 8269516: AArch64: Assembler cleanups Reviewed-by: ngasson, adinn - 8261495: Shenandoah: reconsider update references memory ordering Reviewed-by: zgu, rkennke - 8269478: Shenandoah: gc/shenandoah/mxbeans tests should be more resilient Reviewed-by: rkennke - 8269416: [JVMCI] capture libjvmci crash data to a file Reviewed-by: kvn, dholmes - 8268906: gc/g1/mixedgc/TestOldGenCollectionUsage.java assumes that GCs take 1ms minimum Reviewed-by: kbarrett, ayang, lkorinth - 8263461: jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java uses wrong mechanism to cause evacuation failure Reviewed-by: kbarrett, iwalulya, ayang - ... and 115 more: https://git.openjdk.java.net/jdk/compare/9ac63a6e...d9b654b1 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4645/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4645&range=01 Stats: 31079 lines in 656 files changed: 18219 ins; 10796 del; 2064 mod Patch: https://git.openjdk.java.net/jdk/pull/4645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4645/head:pull/4645 PR: https://git.openjdk.java.net/jdk/pull/4645 From jwilhelm at openjdk.java.net Thu Jul 1 01:06:47 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 1 Jul 2021 01:06:47 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: <9kd-vCEotcwQxZlMbaZi-hGcyK6i6qGQRVefV1PeDBg=.d2fbbe58-7c3a-46d5-b685-66ab35fd8b70@github.com> On Thu, 1 Jul 2021 00:08:51 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 9def3b06 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/9def3b068e9ee065e2e545bb35f8dc56ccfe5955 Stats: 394 lines in 29 files changed: 280 ins; 26 del; 88 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4645 From vromero at openjdk.java.net Thu Jul 1 05:50:25 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 1 Jul 2021 05:50:25 GMT Subject: RFR: 8225559: assertion error at TransTypes.visitApply Message-ID: Please review this PR that is fixing a bug in javac. Depending on variations of the input the compiler fails with an assertion error or with the infamous NPE. So for code like: src/pkg/Bar.java: package pkg; public abstract class Bar { protected Bar() {} protected Bar(Class c) {} } src/Test.java: import pkg.Bar; import java.util.function.Supplier; class Test { public void foo() { supply(getSupplier(new Bar<>(){})); } static Supplier getSupplier(Bar t) { return null; } static void supply(Supplier supplier) {} } see that the new class expression is defining an anonymous class which is invoking a protected constructor in the super class, all of this should just work, and it works if the user doesn't use diamond and instead the type parameters are provided explicitly. So what happens with the diamond? The reason is deep into the speculative attribution machinery, oh boy.... So when we are dealing with diamond expression that define anonymous classes, the speculative attribution will at some point clone that expression but it will nuke its class definition basically in the expression: `new Bar<>(){}` the `{}` will be removed. so we have: `new Bar<>(){} (Original)` `new Bar<>() (Copy1)` but in order for the rest of the code to know that the original expression was actually defining an anonymous class, the compiler does a trick. Which can be seen at: `com.sun.tools.javac.tree.TreeMaker::SpeculativeNewClass` basically an anonymous class which overrides method `JCTree.JCNewClass::classDeclRemoved` is created. But the bug presented itself for cases when the speculative attribution needs to clone `Copy1` and now it doesn't have the `{}`, the class definition, for the cloning code to know that that expression was copied from `Original` which was defining an anonymous class. So we need to double check by making use of method JCTree.JCNewClass::classDeclRemoved which is what this fix is doing. Also it is important to know if the new class expression was defining an anonymous inner class or not because that makes the difference in case the new class expression is accessing a protected constructor as in this case. TIA ------------- Commit messages: - 8225559: assertion error at TransTypes.visitApply Changes: https://git.openjdk.java.net/jdk/pull/4647/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4647&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225559 Stats: 53 lines in 3 files changed: 47 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4647.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4647/head:pull/4647 PR: https://git.openjdk.java.net/jdk/pull/4647 From sadayapalam at openjdk.java.net Thu Jul 1 09:42:03 2021 From: sadayapalam at openjdk.java.net (Srikanth Adayapalam) Date: Thu, 1 Jul 2021 09:42:03 GMT Subject: RFR: 8225559: assertion error at TransTypes.visitApply In-Reply-To: References: Message-ID: <8J8dAFrI-E9H18hU4ujtGjv0hs8R-T9zfNRNQ7z3MVU=.796e4df9-07da-4e02-bae8-54f09dbd9d73@github.com> On Thu, 1 Jul 2021 05:41:40 GMT, Vicente Romero wrote: > Please review this PR that is fixing a bug in javac. Depending on variations of the input the compiler fails with an assertion error or with the infamous NPE. So for code like: > > src/pkg/Bar.java: > > package pkg; > public abstract class Bar { > protected Bar() {} > protected Bar(Class c) {} > } > > src/Test.java: > > import pkg.Bar; > import java.util.function.Supplier; > > class Test { > public void foo() { > supply(getSupplier(new Bar<>(){})); > } > > static Supplier getSupplier(Bar t) { > return null; > } > > static void supply(Supplier supplier) {} > } > > see that the new class expression is defining an anonymous class which is invoking a protected constructor in the super class, all of this should just work, and it works if the user doesn't use diamond and instead the type parameters are provided explicitly. So what happens with the diamond? > > The reason is deep into the speculative attribution machinery, oh boy.... So when we are dealing with diamond expression that define anonymous classes, the speculative attribution will at some point clone that expression but it will nuke its class definition basically in the expression: `new Bar<>(){}` the `{}` will be removed. > > so we have: > `new Bar<>(){} (Original)` > `new Bar<>() (Copy1)` > > but in order for the rest of the code to know that the original expression was actually defining an anonymous class, the compiler does a trick. Which can be seen at: `com.sun.tools.javac.tree.TreeMaker::SpeculativeNewClass` basically an anonymous class which overrides method `JCTree.JCNewClass::classDeclRemoved` is created. But the bug presented itself for cases when the speculative attribution needs to clone `Copy1` and now it doesn't have the `{}`, the class definition, for the cloning code to know that that expression was copied from `Original` which was defining an anonymous class. So we need to double check by making use of method JCTree.JCNewClass::classDeclRemoved which is what this fix is doing. > > Also it is important to know if the new class expression was defining an anonymous inner class or not because that makes the difference in case the new class expression is accessing a protected constructor as in this case. > > TIA Looks reasonable, +1 assuming sanity check done against original test case (and not just the simplified stripped down test case) ------------- Marked as reviewed by sadayapalam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4647 From jlahoda at openjdk.java.net Thu Jul 1 10:13:01 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 1 Jul 2021 10:13:01 GMT Subject: [jdk17] Integrated: 8269354: javac crashes when processing parenthesized pattern in instanceof In-Reply-To: References: Message-ID: On Fri, 25 Jun 2021 14:37:53 GMT, Jan Lahoda wrote: > When having code like: > > if (o instanceof String s) { > System.err.println(s); > } > > > `javac` needs to hoist the `s` binding variable out of the `if` statement. This is done through `BindingContext` in `TransPatterns`. Sometimes, there is no statement out of which the variable would need to be hoisted, like: > > boolean b = o instanceof String s && !s.isEmpty(); > > > so some expressions (`&&` in the example) also serve as a place where the binding variables can be hoisted. With the addition of parenthesized and guarded patterns, the `instanceof` expression needs to be one of such expressions so that in expressions like: > > boolean b = o instanceof (String s && !s.isEmpty()); > > > the `s.isEmpty()` uses the correct translated/hoisted variable. This pull request has now been integrated. Changeset: a8385feb Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk17/commit/a8385feb30bd7bd59bcc808de046fcd2e4fb92c1 Stats: 14 lines in 2 files changed: 7 ins; 0 del; 7 mod 8269354: javac crashes when processing parenthesized pattern in instanceof Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk17/pull/147 From jlahoda at openjdk.java.net Thu Jul 1 10:17:04 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 1 Jul 2021 10:17:04 GMT Subject: RFR: 8225559: assertion error at TransTypes.visitApply In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 05:41:40 GMT, Vicente Romero wrote: > Please review this PR that is fixing a bug in javac. Depending on variations of the input the compiler fails with an assertion error or with the infamous NPE. So for code like: > > src/pkg/Bar.java: > > package pkg; > public abstract class Bar { > protected Bar() {} > protected Bar(Class c) {} > } > > src/Test.java: > > import pkg.Bar; > import java.util.function.Supplier; > > class Test { > public void foo() { > supply(getSupplier(new Bar<>(){})); > } > > static Supplier getSupplier(Bar t) { > return null; > } > > static void supply(Supplier supplier) {} > } > > see that the new class expression is defining an anonymous class which is invoking a protected constructor in the super class, all of this should just work, and it works if the user doesn't use diamond and instead the type parameters are provided explicitly. So what happens with the diamond? > > The reason is deep into the speculative attribution machinery, oh boy.... So when we are dealing with diamond expression that define anonymous classes, the speculative attribution will at some point clone that expression but it will nuke its class definition basically in the expression: `new Bar<>(){}` the `{}` will be removed. > > so we have: > `new Bar<>(){} (Original)` > `new Bar<>() (Copy1)` > > but in order for the rest of the code to know that the original expression was actually defining an anonymous class, the compiler does a trick. Which can be seen at: `com.sun.tools.javac.tree.TreeMaker::SpeculativeNewClass` basically an anonymous class which overrides method `JCTree.JCNewClass::classDeclRemoved` is created. But the bug presented itself for cases when the speculative attribution needs to clone `Copy1` and now it doesn't have the `{}`, the class definition, for the cloning code to know that that expression was copied from `Original` which was defining an anonymous class. So we need to double check by making use of method JCTree.JCNewClass::classDeclRemoved which is what this fix is doing. > > Also it is important to know if the new class expression was defining an anonymous inner class or not because that makes the difference in case the new class expression is accessing a protected constructor as in this case. > > TIA lgtm ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4647 From jlahoda at openjdk.java.net Thu Jul 1 11:36:16 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 1 Jul 2021 11:36:16 GMT Subject: [jdk17] RFR: 8269146: Missing unreported constraints on pattern and other case label combination Message-ID: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> There is a number of constraints on the case label forms - patterns cannot be combined with patterns, etc. Currently, the checks are implemented by checking if there are clashing bindings. But this misses some of the cases which should lead to errors. This patch proposes to implement explicit checks on the structure of the case labels in `Attr.handleSwitch`, rather than relying on clashing bindings. ------------- Commit messages: - Adding test summary. - Improving code. - Merging master into JDK-8269146 - 8269146: Missing unreported constraints on pattern and other case label combination Changes: https://git.openjdk.java.net/jdk17/pull/194/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=194&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269146 Stats: 323 lines in 6 files changed: 259 ins; 41 del; 23 mod Patch: https://git.openjdk.java.net/jdk17/pull/194.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/194/head:pull/194 PR: https://git.openjdk.java.net/jdk17/pull/194 From jlahoda at openjdk.java.net Thu Jul 1 13:26:25 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 1 Jul 2021 13:26:25 GMT Subject: [jdk17] RFR: 8269146: Missing unreported constraints on pattern and other case label combination [v2] In-Reply-To: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> References: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> Message-ID: > There is a number of constraints on the case label forms - patterns cannot be combined with patterns, etc. Currently, the checks are implemented by checking if there are clashing bindings. But this misses some of the cases which should lead to errors. This patch proposes to implement explicit checks on the structure of the case labels in `Attr.handleSwitch`, rather than relying on clashing bindings. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing fallthrough. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/194/files - new: https://git.openjdk.java.net/jdk17/pull/194/files/780a4189..3034355c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=194&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=194&range=00-01 Stats: 31 lines in 2 files changed: 29 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/194.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/194/head:pull/194 PR: https://git.openjdk.java.net/jdk17/pull/194 From vromero at openjdk.java.net Thu Jul 1 13:39:58 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 1 Jul 2021 13:39:58 GMT Subject: RFR: 8225559: assertion error at TransTypes.visitApply In-Reply-To: <8J8dAFrI-E9H18hU4ujtGjv0hs8R-T9zfNRNQ7z3MVU=.796e4df9-07da-4e02-bae8-54f09dbd9d73@github.com> References: <8J8dAFrI-E9H18hU4ujtGjv0hs8R-T9zfNRNQ7z3MVU=.796e4df9-07da-4e02-bae8-54f09dbd9d73@github.com> Message-ID: On Thu, 1 Jul 2021 09:38:56 GMT, Srikanth Adayapalam wrote: > Looks reasonable, > > +1 assuming sanity check done against original test case (and not just the simplified stripped down test case) yes that one pass too, but I will add it to the regression test ------------- PR: https://git.openjdk.java.net/jdk/pull/4647 From duke at openjdk.java.net Thu Jul 1 15:32:04 2021 From: duke at openjdk.java.net (duke) Date: Thu, 1 Jul 2021 15:32:04 GMT Subject: Withdrawn: 8266625: The method DiagnosticSource#findLine returns wrong results when using the boundary values In-Reply-To: References: Message-ID: On Thu, 6 May 2021 13:55:35 GMT, Guoxiong Li wrote: > Hi all, > > Currently, when the file object has N characters, the method `DiagnosticSource#findLine(N)` returns true, which is a wrong result. Becase the position is zero-based, the max index is `N-1`. > > The methods `getLineNumber`, `getColumnNumber` and `getLine`, which use `findLine` internally, would also return wrong results when using the boundary values. > > This patch mainly fixes `DiagnosticSource#findLine(N)` by using the following code. > > > - return bp <= bufLen; > + return bp < bufLen; > > > A corresponding test `DiagnosticSourceTest.java` is added. Then, the usages of `getLineNumber`, `getColumnNumber` and `getLine` need to revised. And two existing tests need to be adjusted. > > Thank you for taking the time to review. > > Best Regards, > --- Guoxiong This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3899 From vromero at openjdk.java.net Thu Jul 1 15:40:32 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 1 Jul 2021 15:40:32 GMT Subject: RFR: 8225559: assertion error at TransTypes.visitApply [v2] In-Reply-To: References: Message-ID: > Please review this PR that is fixing a bug in javac. Depending on variations of the input the compiler fails with an assertion error or with the infamous NPE. So for code like: > > src/pkg/Bar.java: > > package pkg; > public abstract class Bar { > protected Bar() {} > protected Bar(Class c) {} > } > > src/Test.java: > > import pkg.Bar; > import java.util.function.Supplier; > > class Test { > public void foo() { > supply(getSupplier(new Bar<>(){})); > } > > static Supplier getSupplier(Bar t) { > return null; > } > > static void supply(Supplier supplier) {} > } > > see that the new class expression is defining an anonymous class which is invoking a protected constructor in the super class, all of this should just work, and it works if the user doesn't use diamond and instead the type parameters are provided explicitly. So what happens with the diamond? > > The reason is deep into the speculative attribution machinery, oh boy.... So when we are dealing with diamond expression that define anonymous classes, the speculative attribution will at some point clone that expression but it will nuke its class definition basically in the expression: `new Bar<>(){}` the `{}` will be removed. > > so we have: > `new Bar<>(){} (Original)` > `new Bar<>() (Copy1)` > > but in order for the rest of the code to know that the original expression was actually defining an anonymous class, the compiler does a trick. Which can be seen at: `com.sun.tools.javac.tree.TreeMaker::SpeculativeNewClass` basically an anonymous class which overrides method `JCTree.JCNewClass::classDeclRemoved` is created. But the bug presented itself for cases when the speculative attribution needs to clone `Copy1` and now it doesn't have the `{}`, the class definition, for the cloning code to know that that expression was copied from `Original` which was defining an anonymous class. So we need to double check by making use of method JCTree.JCNewClass::classDeclRemoved which is what this fix is doing. > > Also it is important to know if the new class expression was defining an anonymous inner class or not because that makes the difference in case the new class expression is accessing a protected constructor as in this case. > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4647/files - new: https://git.openjdk.java.net/jdk/pull/4647/files/abe51ca3..1f859463 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4647&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4647&range=00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4647.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4647/head:pull/4647 PR: https://git.openjdk.java.net/jdk/pull/4647 From vromero at openjdk.java.net Thu Jul 1 16:21:09 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 1 Jul 2021 16:21:09 GMT Subject: Integrated: 8225559: assertion error at TransTypes.visitApply In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 05:41:40 GMT, Vicente Romero wrote: > Please review this PR that is fixing a bug in javac. Depending on variations of the input the compiler fails with an assertion error or with the infamous NPE. So for code like: > > src/pkg/Bar.java: > > package pkg; > public abstract class Bar { > protected Bar() {} > protected Bar(Class c) {} > } > > src/Test.java: > > import pkg.Bar; > import java.util.function.Supplier; > > class Test { > public void foo() { > supply(getSupplier(new Bar<>(){})); > } > > static Supplier getSupplier(Bar t) { > return null; > } > > static void supply(Supplier supplier) {} > } > > see that the new class expression is defining an anonymous class which is invoking a protected constructor in the super class, all of this should just work, and it works if the user doesn't use diamond and instead the type parameters are provided explicitly. So what happens with the diamond? > > The reason is deep into the speculative attribution machinery, oh boy.... So when we are dealing with diamond expression that define anonymous classes, the speculative attribution will at some point clone that expression but it will nuke its class definition basically in the expression: `new Bar<>(){}` the `{}` will be removed. > > so we have: > `new Bar<>(){} (Original)` > `new Bar<>() (Copy1)` > > but in order for the rest of the code to know that the original expression was actually defining an anonymous class, the compiler does a trick. Which can be seen at: `com.sun.tools.javac.tree.TreeMaker::SpeculativeNewClass` basically an anonymous class which overrides method `JCTree.JCNewClass::classDeclRemoved` is created. But the bug presented itself for cases when the speculative attribution needs to clone `Copy1` and now it doesn't have the `{}`, the class definition, for the cloning code to know that that expression was copied from `Original` which was defining an anonymous class. So we need to double check by making use of method JCTree.JCNewClass::classDeclRemoved which is what this fix is doing. > > Also it is important to know if the new class expression was defining an anonymous inner class or not because that makes the difference in case the new class expression is accessing a protected constructor as in this case. > > TIA This pull request has now been integrated. Changeset: de61328d Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/de61328d30e4d022c2609b2947bafe4b36cc1293 Stats: 59 lines in 3 files changed: 53 ins; 4 del; 2 mod 8225559: assertion error at TransTypes.visitApply Reviewed-by: sadayapalam, jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/4647 From jwilhelm at openjdk.java.net Fri Jul 2 00:25:29 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 2 Jul 2021 00:25:29 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8269745: [JVMCI] restore original qualified exports to Graal - 8268566: java/foreign/TestResourceScope.java timed out - 8260684: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed out - 8269580: assert(is_valid()) failed: invalid register (-1) - 8269704: Typo in j.t.Normalizer.normalize() - 8269354: javac crashes when processing parenthesized pattern in instanceof - 8269285: Crash/miscompile in CallGenerator::for_method_handle_inline after JDK-8191998 - 8269088: C2 fails with assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect - 8269230: C2: main loop in micro benchmark never executed - ... and 3 more: https://git.openjdk.java.net/jdk/compare/de61328d...5515a992 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4661&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4661&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4661/files Stats: 996 lines in 26 files changed: 843 ins; 64 del; 89 mod Patch: https://git.openjdk.java.net/jdk/pull/4661.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4661/head:pull/4661 PR: https://git.openjdk.java.net/jdk/pull/4661 From jwilhelm at openjdk.java.net Fri Jul 2 01:12:34 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 2 Jul 2021 01:12:34 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 133 commits: - Merge - 8225559: assertion error at TransTypes.visitApply Reviewed-by: sadayapalam, jlahoda - 8268960: com/sun/net/httpserver/Headers.java: Ensure mutators normalize keys and disallow null for keys and values Reviewed-by: chegar, dfuchs, michaelm - 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title Reviewed-by: azvegint, serb - 8133873: Simplify {Register,Unregister}NMethodOopClosure Reviewed-by: tschatzl, kbarrett - 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message Reviewed-by: egahlin - 8266746: C1: Replace UnsafeGetRaw with UnsafeGet when setting up OSR entry block Replace UnsafeGetRaw with UnsafeGetObject when setting up OSR entry block, and rename Unsafe{Get,Put}Object to Unsafe{Get,Put} Reviewed-by: thartmann, dlong, mdoerr - 8268870: Remove dead code in metaspaceShared Reviewed-by: tschatzl - Merge - 8268637: Update --release 17 symbol information for JDK 17 build 28 Reviewed-by: iris - ... and 123 more: https://git.openjdk.java.net/jdk/compare/a4d2a9a7...5515a992 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4661/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4661&range=01 Stats: 32483 lines in 677 files changed: 18918 ins; 11377 del; 2188 mod Patch: https://git.openjdk.java.net/jdk/pull/4661.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4661/head:pull/4661 PR: https://git.openjdk.java.net/jdk/pull/4661 From jwilhelm at openjdk.java.net Fri Jul 2 01:12:36 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Fri, 2 Jul 2021 01:12:36 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: <9541FIty7ivYR6t4zu5TZr5R_tIsqCHUaP4Wmo7q1nM=.6563c5be-64bb-40aa-a0e4-4facdfb85b2c@github.com> On Fri, 2 Jul 2021 00:18:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: b0e18679 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/b0e186792e816be30347dacfd88b8e55476584e7 Stats: 996 lines in 26 files changed: 843 ins; 64 del; 89 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4661 From jlahoda at openjdk.java.net Fri Jul 2 12:18:11 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 2 Jul 2021 12:18:11 GMT Subject: [jdk17] RFR: 8268859: jshell throws exception while parsing illegal "case true" Message-ID: <_vtnRjce-_cQvI8ObT24pGzzLjZAnjJ6zY02GneyFtk=.126743f3-7e5e-4397-85d0-0b5bc34edfb9@github.com> Currently, broken case labels like `case true t` parse as patterns, whose type is `true`, which then fails later during annotation handling. This patch is trying to improve (and fix) the pattern/expression disambiguation again, making it more explicit than before. With this patch, only labels that begin with ` ` should be considered patterns. The recently added no-preview part of `SwitchErrors` is moved to `PatternErrorRecovery.java`, because that indeed turned out to be difficult to maintain. ------------- Commit messages: - Formatting, cleanup. - Adding missing files. - Readding SuppressWarnings. - Merge branch 'master' into JDK-8268859 - Improving disambiguation of expressions and patterns. - Merge branch 'master' into JDK-8268859 - 8268859: jshell throws exception while parsing illegal "case true" Changes: https://git.openjdk.java.net/jdk17/pull/202/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=202&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268859 Stats: 548 lines in 12 files changed: 279 ins; 206 del; 63 mod Patch: https://git.openjdk.java.net/jdk17/pull/202.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/202/head:pull/202 PR: https://git.openjdk.java.net/jdk17/pull/202 From james.laskey at oracle.com Fri Jul 2 12:47:43 2021 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 2 Jul 2021 12:47:43 +0000 Subject: JDK-8254073, unicode escape preprocessing, and \u005C In-Reply-To: References: <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com> <86520066-93a7-d24e-c86e-e9dda6b9bc9b@oracle.com> <2feaea08-2217-a094-93ef-fc519cab793e@oracle.com> Message-ID: Just so it doesn't look like I went rogue with the bug fix (https://bugs.openjdk.java.net/browse/JDK-8269290), I would like a consensus ruling on which is the bug fix I should use; correct fix: interpretAsPerJLS(); faithful fix: if (sourceLevel <= 15) interpretOldWay(); else interpretAsPerJLS(); status quo fix: interpretOldWay(); I'm assuming correct fix, but others may have different assumptions. Cheers, -- Jim On Jun 25, 2021, at 4:04 PM, Alex Buckley > wrote: I filed https://bugs.openjdk.java.net/browse/JDK-8269406 with some additional discussion about what the result of the first lexical translation step is really meant to be. Please take a look if you are familiar with the three-step translation described in JLS 3.2, and care about how the input stream is processed. Alex On 6/22/2021 10:38 AM, Alex Buckley wrote: I am minded to extend the final note in JLS 3.3 to help people understand the multi-level escape story in play when they experiment with Unicode escapes. Perhaps it will also improve some javac error messages or test cases. Let me know what you think of this: ----- For example, the input stream \u005cu005a results in the six characters \ u 0 0 5 a, because 005c is the Unicode value for \. It does not result in the character Z, which is Unicode character 005a, because the \ that resulted from the \u005c is not interpreted as the start of a further Unicode escape. Note that \u005cu005a cannot be written in a string literal to denote the six characters \ u 0 0 5 a. This is because the first two characters resulting from translation, \ and u, are interpreted in a string literal as an illegal escape sequence (3.10.7). Fortunately, the rule about contiguous \ characters helps programmers to craft input streams that denote Unicode escapes in a string literal. Denoting the six characters \ u 0 0 5 a in a string literal simply requires another \ to be written adjacent to the existing \, such as in "Z is \\u005a". This works because the second \ in the input stream \\u005a is not eligible, so the first \ and second \ are preserved as raw input characters; they are subsequently interpreted in a string literal as the escape sequence for a backslash, resulting in the desired six characters \ u 0 0 5 a. Without the rule, the input stream \\u005a would be translated as the raw input character \ followed by the Unicode escape \u005a (Z), but \Z is an illegal escape sequence in a string literal. The rule also allows programmers to craft input streams that denote escape sequences in a string literal. For example, the input stream \\\u006e results in the three characters \ \ n because the third \ is eligible and thus \u006e is translated to n, while the first \ and second \ are preserved as raw input characters. The three characters \ \ n are subsequently interpreted in a string literal as \ n which denotes the escape sequence for a linefeed. (The input stream \\\u006e may also be written as \u005c\u005c\u006e.) ----- Alex On 6/21/2021 4:41 PM, Alex Buckley wrote: There's no question that the first six raw input characters \ u 0 0 5 c are identified as a Unicode escape \u005c and translated to a backslash. The question is whether that backslash is then treated as: 1. a raw input character \ that is followed by seven more raw input characters \ \ u 0 0 5 d For these *eight* raw input characters, there are three raw input character \'s in a row. Due to contiguous-\ counting, the third raw input character \ is eligible to begin a Unicode escape; the first and second pass through and you get \ \ ] which further translates within a string literal as \] or 2. something which is independent of the subsequent seven raw input characters \ \ u 0 0 5 d For those *seven* subsequent raw input characters, there are two raw input character \'s in a row. Due to contiguous-\ counting, the second raw input character \ is not eligible to begin a Unicode escape, so all seven raw input characters pass through. You get (including the first "independent" backslash) \ \ \ u 0 0 5 d The contiguous-\ counting is due to the fact that \\ is the escape sequence for backslash in a string literal, so we don't want too many raw \ input character to "disappear" into Unicode escapes. The JDK 15 behavior was #1. That looks correct to me. \ u 0 0 5 c becomes a raw input character \ that cannot serve as the opening backslash for an *immediate* Unicode escape (the classic JLS 3.3 scenario of \u005cu005a) but that can serve as a raw input character for the purpose of skipping over \\ pairs (the purpose of contiguous-\ counting) in order for a *later* Unicode escape to be recognized (\u005d). Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them? Where JLS 3.3 says "translating the ASCII characters \u followed by four hexadecimal digits to the UTF-16 code unit (?3.1) for the indicated hexadecimal value", it really means "translating the ASCII characters \u followed by four hexadecimal digits to *a raw input character which denotes* the UTF-16 code unit (?3.1) for the indicated hexadecimal value". Thus, the later clause "for each raw input character that is a backslash \, input processing must consider how many other [raw input] \ characters contiguously precede it" can be seen more easily to include characters that result from Unicode escape processing. Alex On 6/21/2021 2:56 PM, Jim Laskey wrote: "\u005C? should have been treated as a backslash. Will check into it. Cheers, ? Jim ?? On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon > wrote: ? class T { public static void main(String[] args) { System.err.println("\u005C\\u005D"); } } Before JDK-8254073, this prints `\]`. After JDK-8254073, unicode escape processing results in `\\\u005D`, which results in an 'invalid escape' error for `\u`. Was that deliberate? JLS 3.3 says for each raw input character that is a backslash \, input processing must consider how many other \ characters contiguously precede it, separating it from a non-\ character or the start of the input stream. If this number is even, then the \ is eligible to begin a Unicode escape; if the number is odd, then the \ is not eligible to begin a Unicode escape. The difference is in whether `\u005C` (the unicode escape for `\`) counts as one of the `\` preceding a valid unicode escape. Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them? JLS 3.3 also mentions that a "character produced by a Unicode escape does not participate in further Unicode escapes", but I'm not sure if that applies here, since in the pre-JDK-8254073 interpretation the unicode-escaped backslash isn't really 'participating' in the second unicode escape. Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.java.net Fri Jul 2 13:26:12 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 2 Jul 2021 13:26:12 GMT Subject: [jdk17] RFR: 8269802: javac fails to compile nested pattern matching switches Message-ID: <-nGpz8-kJwEKwA-NHMb6I7PFpV_zvLnTc-OELN3s5kU=.2e33bae4-57ee-4b2e-9b8d-3bd329ff1b5c@github.com> There are two places which where `TransPatterns` is mistakenly not translating a subtree: the statements for non-pattern cases, and the selector. This PR is fixing that by translating the statements and selector. ------------- Commit messages: - Neeed to translate switch selectors for pattern matching switches. - 8269802: javac fails to compile nested pattern matching switches Changes: https://git.openjdk.java.net/jdk17/pull/203/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=203&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269802 Stats: 124 lines in 2 files changed: 123 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/203.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/203/head:pull/203 PR: https://git.openjdk.java.net/jdk17/pull/203 From gli at openjdk.java.net Sat Jul 3 19:37:02 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 3 Jul 2021 19:37:02 GMT Subject: RFR: 8269738: AssertionError when combining pattern maching and function closure Message-ID: Hi all, The method `TransPatterns.BasicBindingContext::bindingDeclared` uses `varSymbol.owner` to construct a new `VarSymbol`. res = new VarSymbol(varSymbol.flags(), varSymbol.name, varSymbol.type, varSymbol.owner); But the `varSymbol.owner` may be also a `VarSymbol` when it is at the `init` clause of the static variables or instance variables. You can see the following code. The `owner` of the `Interger i` is `staticNum1` or `instanceNum1` which is `VarSymbol`. static Number num1 = 1; static Number staticNum1 = (num1 instanceof Integer i) ? ((Supplier) () -> i).get() : null; Number instanceNum1 = (num1 instanceof Integer i) ? ((Supplier) () -> i).get() : null; Then, the class `LambdaToMethod` can't capture the expected variables `Integer i` and the following phases such as `Gen` may fail or throw exceptions. This patch uses the `currentMethodSym` which means a class or instance field initializer to replace `varSymbol.owner` and adds the corresponding test. --- And I have a problem: > The `owner` of the `Interger i` is `staticNum1` or `instanceNum1` which is `VarSymbol`. The statement above means the `env.info.scope.owner` in the method `Attr::visitBindingPattern` is a `VarSymbol`. Is it a expected result? Or the original `env.info.scope.owner` should be modified to a class or instance field initializer which the following phases need. // Attr.java public void visitBindingPattern(JCBindingPattern tree) { ...... BindingSymbol v = new BindingSymbol(tree.var.mods.flags, tree.var.name, tree.var.vartype.type, env.info.scope.owner); ...... } --- Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 8269738: AssertionError when combining pattern maching and function closure Changes: https://git.openjdk.java.net/jdk/pull/4678/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4678&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269738 Stats: 20 lines in 2 files changed: 18 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4678.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4678/head:pull/4678 PR: https://git.openjdk.java.net/jdk/pull/4678 From gli at openjdk.java.net Sun Jul 4 18:21:11 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Sun, 4 Jul 2021 18:21:11 GMT Subject: RFR: 8269113: Javac throws when compiling switch (null) Message-ID: Hi all, When we use `switch(null)` in the source code, the type of the selector is `BottomType`. So the statement `Type seltype = selector.type;` of the method `TransPatterns::handleSwitch` will get a `BottomType`. Then compiler mistakenly uses this `BottomType` to construct a new `VarSymbol`. VarSymbol temp = new VarSymbol(Flags.SYNTHETIC, names.fromString("selector" + tree.pos + target.syntheticNameChar() + "temp"), seltype, // <--------here is a BottomType currentMethodSym); At last, when the compiler uses the new `VarSymbol temp` to construct a new `JCVariableDecl`(the code shown as below), it crashes at the method `TreeMaker::Type` because the method `TreeMaker::Type` can't handle the type `BottomType`. statements.append(make.at(tree.pos).VarDef(temp, !hasNullCase ? attr.makeNullCheck(selector) : selector)); This patch changes the type from `BottomType` to `syms.objectType` and adds the corresponding test. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 8269113: Javac throws when compiling switch (null) Changes: https://git.openjdk.java.net/jdk/pull/4679/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4679&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269113 Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4679.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4679/head:pull/4679 PR: https://git.openjdk.java.net/jdk/pull/4679 From mcimadamore at openjdk.java.net Tue Jul 6 09:49:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 6 Jul 2021 09:49:50 GMT Subject: [jdk17] RFR: 8269802: javac fails to compile nested pattern matching switches In-Reply-To: <-nGpz8-kJwEKwA-NHMb6I7PFpV_zvLnTc-OELN3s5kU=.2e33bae4-57ee-4b2e-9b8d-3bd329ff1b5c@github.com> References: <-nGpz8-kJwEKwA-NHMb6I7PFpV_zvLnTc-OELN3s5kU=.2e33bae4-57ee-4b2e-9b8d-3bd329ff1b5c@github.com> Message-ID: On Fri, 2 Jul 2021 13:19:08 GMT, Jan Lahoda wrote: > There are two places which where `TransPatterns` is mistakenly not translating a subtree: the statements for non-pattern cases, and the selector. This PR is fixing that by translating the statements and selector. Looks good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/203 From mcimadamore at openjdk.java.net Tue Jul 6 09:57:53 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 6 Jul 2021 09:57:53 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v6] In-Reply-To: References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: On Wed, 30 Jun 2021 10:23:32 GMT, Jan Lahoda wrote: >> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`. >> >> How does this look? > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Reflecting review comments. > - Merge branch 'master' into JDK-8268766 > - Improving javadoc. > - Updating javadoc, as suggested. > - Updating javadoc, code and tests as suggested. > - Creating a new bootstrap method for (pattern matching) enum switches, as suggested. > - Adding and fixing test. > - Merging master. > - 8268766: Desugaring of pattern matching enum switch should be improved Looks good - added minor cosmetic comments src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 205: > 203: * > 204: * @param lookup Represents a lookup context with the accessibility > 205: * privileges of the caller. When used with {@code invokedynamic}, Suggestion: * privileges of the caller. When used with {@code invokedynamic}, src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 216: > 214: * @throws NullPointerException if any argument is {@code null} > 215: * @throws IllegalArgumentException if any element in the labels array is null, if the > 216: * invocation type is not a method type of first parameter of an enum type, Suggestion: * invocation type is not a method type whose first parameter type is an enum type, src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 217: > 215: * @throws IllegalArgumentException if any element in the labels array is null, if the > 216: * invocation type is not a method type of first parameter of an enum type, > 217: * second parameter of type {@code int} and with {@code int} as its return type, Suggestion: * second parameter of type {@code int} and whose return type is {@code int}, ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/81 From prappo at openjdk.java.net Tue Jul 6 10:02:52 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 6 Jul 2021 10:02:52 GMT Subject: RFR: JDK-8268420: new Reporter method to report a diagnostic within a DocTree node [v2] In-Reply-To: References: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> Message-ID: On Wed, 16 Jun 2021 17:18:31 GMT, Jonathan Gibbons wrote: >> Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string. >> >> This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc. >> >> The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes. >> >> There are some cosmetic cleanups that were made while exploring the current solution. >> >> The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback Shouldn't this change also add a corresponding method to `jdk.javadoc.internal.doclets.toolkit.Messages` similarly to how it was done for `Reporter.print(Diagnostic.Kind, FileObject, int, int, int, String)`? ------------- PR: https://git.openjdk.java.net/jdk/pull/4489 From mcimadamore at openjdk.java.net Tue Jul 6 10:26:00 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 6 Jul 2021 10:26:00 GMT Subject: [jdk17] RFR: 8269146: Missing unreported constraints on pattern and other case label combination [v2] In-Reply-To: References: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> Message-ID: On Thu, 1 Jul 2021 13:26:25 GMT, Jan Lahoda wrote: >> There is a number of constraints on the case label forms - patterns cannot be combined with patterns, etc. Currently, the checks are implemented by checking if there are clashing bindings. But this misses some of the cases which should lead to errors. This patch proposes to implement explicit checks on the structure of the case labels in `Attr.handleSwitch`, rather than relying on clashing bindings. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing fallthrough. I wonder if all the `wasDefault` etc tests, to check compatibility between different kind of labels couldn't be moved when at parse time. The code in attr is already quite convoluted, and it seems to be doing many things at once - if there are checks which depend on flow analysis, of course these should remain in Attr - but there seems to be a lot of structural checks which do not really depend on attribution which could be caught a lot earlier, and probably giving better error messages too. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1684: > 1682: boolean hasTotalPattern = false; // Is there a total pattern? > 1683: boolean hasNullPattern = false; // Is there a null pattern? > 1684: boolean wasConstant = false; // Seen a constant in the same case label I'd suggest to move the `wasXYZ` variables inside the case label loop - since they are not meant to be variables that are global to the entire switch construct? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1787: > 1785: if (wasPattern || wasConstant || wasDefault || > 1786: (wasNullPattern && (!isTypePattern || wasNonEmptyFallThrough))) { > 1787: log.error(pat.pos(), Errors.FlowsThroughToPattern); Is this a good error message for the condition? E.g. it seems like here we're mostly complaining about some illegal mix of constant, default and pattern labels - which seems more something to do with well-formedness than with fallthrough? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1829: > 1827: boolean completesNormally = c.caseKind == CaseTree.CaseKind.STATEMENT ? flow.aliveAfter(caseEnv, c, make) : false; > 1828: > 1829: if (c.stats.nonEmpty()) { This initialization should probably go at the beginning of the for loop block? ------------- PR: https://git.openjdk.java.net/jdk17/pull/194 From mcimadamore at openjdk.java.net Tue Jul 6 10:35:48 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 6 Jul 2021 10:35:48 GMT Subject: [jdk17] RFR: 8268859: jshell throws exception while parsing illegal "case true" In-Reply-To: <_vtnRjce-_cQvI8ObT24pGzzLjZAnjJ6zY02GneyFtk=.126743f3-7e5e-4397-85d0-0b5bc34edfb9@github.com> References: <_vtnRjce-_cQvI8ObT24pGzzLjZAnjJ6zY02GneyFtk=.126743f3-7e5e-4397-85d0-0b5bc34edfb9@github.com> Message-ID: On Fri, 2 Jul 2021 12:11:52 GMT, Jan Lahoda wrote: > Currently, broken case labels like `case true t` parse as patterns, whose type is `true`, which then fails later during annotation handling. This patch is trying to improve (and fix) the pattern/expression disambiguation again, making it more explicit than before. With this patch, only labels that begin with ` ` should be considered patterns. > > The recently added no-preview part of `SwitchErrors` is moved to `PatternErrorRecovery.java`, because that indeed turned out to be difficult to maintain. Parser changes look good - splitting lambda analysis from pattern analysis and finding commonalities (e.g. skipping annotations) seems like a wise move. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/202 From jlahoda at openjdk.java.net Tue Jul 6 15:02:56 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 6 Jul 2021 15:02:56 GMT Subject: [jdk17] RFR: 8269146: Missing unreported constraints on pattern and other case label combination [v2] In-Reply-To: References: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> Message-ID: <9dS24gKQCcwxq4JIqT0iOvfhsoDJsIs7qmg4Jw66E-A=.ba7a715c-170c-4f05-9e97-e7b1dd6f96b0@github.com> On Tue, 6 Jul 2021 10:16:42 GMT, Maurizio Cimadamore wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing fallthrough. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1684: > >> 1682: boolean hasTotalPattern = false; // Is there a total pattern? >> 1683: boolean hasNullPattern = false; // Is there a null pattern? >> 1684: boolean wasConstant = false; // Seen a constant in the same case label > > I'd suggest to move the `wasXYZ` variables inside the case label loop - since they are not meant to be variables that are global to the entire switch construct? I agree it would be much better to have the flags closer, but the flags sadly generally apply across case clauses. The conditions don't allow `case , default:` as well as `case : /*no statements*/ case default:`, because both are `SwitchLabel`s. So we need to keep information across `case` clauses if the case has an empty list of statements, and in some cases even if the list of statements is not empty, but there is a fall-through to the following case (which is to prevent cases like `case null: System.err.println(); /*no break*/ case Integer i:`). ------------- PR: https://git.openjdk.java.net/jdk17/pull/194 From mcimadamore at openjdk.java.net Tue Jul 6 17:54:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 6 Jul 2021 17:54:50 GMT Subject: [jdk17] RFR: 8269146: Missing unreported constraints on pattern and other case label combination [v2] In-Reply-To: <9dS24gKQCcwxq4JIqT0iOvfhsoDJsIs7qmg4Jw66E-A=.ba7a715c-170c-4f05-9e97-e7b1dd6f96b0@github.com> References: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> <9dS24gKQCcwxq4JIqT0iOvfhsoDJsIs7qmg4Jw66E-A=.ba7a715c-170c-4f05-9e97-e7b1dd6f96b0@github.com> Message-ID: On Tue, 6 Jul 2021 14:59:39 GMT, Jan Lahoda wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1684: >> >>> 1682: boolean hasTotalPattern = false; // Is there a total pattern? >>> 1683: boolean hasNullPattern = false; // Is there a null pattern? >>> 1684: boolean wasConstant = false; // Seen a constant in the same case label >> >> I'd suggest to move the `wasXYZ` variables inside the case label loop - since they are not meant to be variables that are global to the entire switch construct? > > I agree it would be much better to have the flags closer, but the flags sadly generally apply across case clauses. The conditions don't allow `case , default:` as well as `case : /*no statements*/ case default:`, because both are `SwitchLabel`s. So we need to keep information across `case` clauses if the case has an empty list of statements, and in some cases even if the list of statements is not empty, but there is a fall-through to the following case (which is to prevent cases like `case null: System.err.println(); /*no break*/ case Integer i:`). OK, thanks for the clarification, I think I now get what the code is trying to do and the fact that multiple `cases` (even if separated by commas) are really dealt with separately by the logic, so you need to keep these flags in scope for longer. I still think that some of these checks could be perhaps moved closer to parser - and then in Attr we could check stuff that depends on types (e.g. dominance), or stuff that depends on control flow (e.g. cannot fall through to a pattern). I understand that the code was like this (e.g. duplicate labels, or duplicate defaults has always been caught in Attr) - but as the number of checks grows larger, it feels like keep adding checks in Attr doesn't scale very well. ------------- PR: https://git.openjdk.java.net/jdk17/pull/194 From mcimadamore at openjdk.java.net Tue Jul 6 17:54:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 6 Jul 2021 17:54:50 GMT Subject: [jdk17] RFR: 8269146: Missing unreported constraints on pattern and other case label combination [v2] In-Reply-To: References: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> Message-ID: <9Pm1_9X_FcxkjwgrPL1kXIoJ2sj5_d1qEj6gFJdU0ZQ=.35d3a7b5-99a3-431e-8c26-fbfd336cdc95@github.com> On Thu, 1 Jul 2021 13:26:25 GMT, Jan Lahoda wrote: >> There is a number of constraints on the case label forms - patterns cannot be combined with patterns, etc. Currently, the checks are implemented by checking if there are clashing bindings. But this misses some of the cases which should lead to errors. This patch proposes to implement explicit checks on the structure of the case labels in `Attr.handleSwitch`, rather than relying on clashing bindings. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing fallthrough. Approving for now, perhaps with a view to investigate ways to split the checks at a later point. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/194 From jjg at openjdk.java.net Tue Jul 6 18:40:16 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 6 Jul 2021 18:40:16 GMT Subject: RFR: JDK-8249634: doclint should report implicit constructor as missing javadoc comments Message-ID: Please review a simple update to doclint, to generate messages for the "effectively missing" comment on default constructors on "normal" classes (not enums classes or record classes.) The change does affect a bunch of tests, mostly doclint tests, which all use atypical "toy" classes to host the comments to be tested, and which generally do not have explicit constructors ... and so trigger the new warning about using default constructors. There is no one solution applied to all tests. The general theme of the changes is to minimize the changes, and in almost all cases to avoid changing any "golden files" or "expected output". The following techniques are used to modify tests: where it does not significantly interact with other test options, disable the check for missing comments when that is not the primary function of the test where it would not affect any line numbers in any expected output, add an explicit no-args constructor at the end of the class body add an explicit no-args constructor on the same line as the opening { of the class body (i.e.in order not to change line numbers in reference output) ------------- Commit messages: - fix trailing whitespace - JDK-8249634: doclint should report implicit constructor as missing javadoc comments Changes: https://git.openjdk.java.net/jdk/pull/4695/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4695&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249634 Stats: 235 lines in 76 files changed: 121 ins; 4 del; 110 mod Patch: https://git.openjdk.java.net/jdk/pull/4695.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4695/head:pull/4695 PR: https://git.openjdk.java.net/jdk/pull/4695 From jlahoda at openjdk.java.net Tue Jul 6 20:29:47 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 6 Jul 2021 20:29:47 GMT Subject: RFR: 8266407: remove jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES In-Reply-To: References: Message-ID: <2ovX7bjHRuUbakjgD91wxfwrR9DJ0_ikRwUaVwFKCfs=.cd3f652c-3766-4aa8-881b-71e51924ab7d@github.com> On Wed, 23 Jun 2021 20:57:24 GMT, Vicente Romero wrote: > Enum constant: jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES was not removed when Sealed Classes were made final because the build was failing without it. Now that the feature is final we should be able to safely removed it. This is the intention of this patch. > > TIA, > Vicente lgtm ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4578 From vromero at openjdk.java.net Tue Jul 6 23:08:57 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 6 Jul 2021 23:08:57 GMT Subject: Integrated: 8266407: remove jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES In-Reply-To: References: Message-ID: On Wed, 23 Jun 2021 20:57:24 GMT, Vicente Romero wrote: > Enum constant: jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES was not removed when Sealed Classes were made final because the build was failing without it. Now that the feature is final we should be able to safely removed it. This is the intention of this patch. > > TIA, > Vicente This pull request has now been integrated. Changeset: 01c29d8f Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/01c29d8f2c865009c0d5379ba2e2cd4d3015f018 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod 8266407: remove jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/4578 From alex.buckley at oracle.com Tue Jul 6 23:26:40 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 6 Jul 2021 16:26:40 -0700 Subject: JDK-8254073, unicode escape preprocessing, and \u005C In-Reply-To: References: <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com> <86520066-93a7-d24e-c86e-e9dda6b9bc9b@oracle.com> <2feaea08-2217-a094-93ef-fc519cab793e@oracle.com> Message-ID: (I slightly reordered the table in JDK-8269290 in support of the following exposition.) Since time immemorial, X = "\u005C\\u005D" has printed `\]` on the grounds that the six opening characters \ u 0 0 5 C form a backslash for the purpose of counting how many backslash characters contiguously precede the backslash in the final six characters \ u 0 0 5 D. (Two, making the backslash in \ u 0 0 5 D eligible to begin a Unicode escape.) Given Y = "\u005C\u005C\u005D", it's consistent for the six opening characters \ u 0 0 5 C to again form a backslash for the purpose of counting how many backslash characters contiguously precede the backslash in the middle six characters \ u 0 0 5 C. Thus, "\u005C\u005C..." is treated the same as "\\u005C...". I acknowledge this is an incompatible change, but consider the alternative. If the six opening characters *didn't* contribute a backslash to the count for \ u 0 0 5 C in the Y case, then the same six opening characters wouldn't contribute a backslash to the count for \ u 0 0 5 D in the X case. (In this alternative universe, people take the rule "The character produced by a Unicode escape does not participate in further Unicode escapes." literally.) Thus, in the X case, there would only be one backslash, denoted by the ASCII character, preceding the final six characters \ u 0 0 5 D ==> the \ in \ u 0 0 5 D would not be eligible ==> X would lex as \ \ \ u 0 0 5 D and print as `\\u005D` which is plain wrong. (Maybe there is some application of the "longest possible translation" rule from 3.2 that lets the same six opening characters become a backslash-that-counts in X but not become a backslash-that-counts in Y. However, I do not know how to describe that application.) Here's another test case for the CSR. JDK 15 does this: jshell> System.out.println("\\u005D"); \u005D jshell> System.out.println("\u005C\u005D"); | Error: | illegal escape character | System.out.println("\u005C\u005D"); | ^ With my consistency-first approach, the Z = "\u005C\u005D" case is legal, which seems far more reasonable than illegal. The six opening characters \ u 0 0 5 C form a backslash for the purpose of counting how many backslash characters contiguously precede the backslash in the final six characters \ u 0 0 5 D. (One, meaning the backslash in \ u 0 0 5 D is not eligible to begin a Unicode escape.) The result would be \ \ u 0 0 5 D which would print as `\u005D`. Net net, I favor the correct fix -- and lots more test cases in the JCK. Alex On 7/2/2021 5:47 AM, Jim Laskey wrote: > Just so it doesn't look like I went rogue with the bug fix > (https://bugs.openjdk.java.net/browse/JDK-8269290 > ), I would like a > consensus ruling on which is the?bug?fix I should use; > > correct fix: > > interpretAsPerJLS(); > > > faithful fix: > > if (sourceLevel <= 15) > ? ? interpretOldWay(); > ? ? ? ? else > ? ? interpretAsPerJLS(); > > status quo fix: > > interpretOldWay(); > > I'm assuming correct fix, but others may have different assumptions. > > Cheers, > > -- Jim > >> On Jun 25, 2021, at 4:04 PM, Alex Buckley > > wrote: >> >> I filed https://bugs.openjdk.java.net/browse/JDK-8269406 >> with some >> additional discussion about what the result of the first lexical >> translation step is really meant to be. >> >> Please take a look if you are familiar with the three-step translation >> described in JLS 3.2, and care about how the input stream is processed. >> >> Alex >> >> On 6/22/2021 10:38 AM, Alex Buckley wrote: >>> I am minded to extend the final note in JLS 3.3 to help people >>> understand the multi-level escape story in play when they experiment >>> with Unicode escapes. Perhaps it will also improve some javac error >>> messages or test cases. Let me know what you think of this: >>> ----- >>> For example, the input stream \u005cu005a results in the six >>> characters \ u 0 0 5 a, because 005c is the Unicode value for \. It >>> does not result in the character Z, which is Unicode character 005a, >>> because the \ that resulted from the \u005c is not interpreted as the >>> start of a further Unicode escape. >>> Note that \u005cu005a cannot be written in a string literal to denote >>> the six characters \ u 0 0 5 a. This is because the first two >>> characters resulting from translation, \ and u, are interpreted in a >>> string literal as an illegal escape sequence (3.10.7). >>> Fortunately, the rule about contiguous \ characters helps programmers >>> to craft input streams that denote Unicode escapes in a string >>> literal. Denoting the six characters \ u 0 0 5 a in a string literal >>> simply requires another \ to be written adjacent to the existing \, >>> such as in "Z is \\u005a". This works because the second \ in the >>> input stream \\u005a is not eligible, so the first \ and second \ are >>> preserved as raw input characters; they are subsequently interpreted >>> in a string literal as the escape sequence for a backslash, resulting >>> in the desired six characters \ u 0 0 5 a. Without the rule, the >>> input stream \\u005a would be translated as the raw input character \ >>> followed by the Unicode escape \u005a (Z), but \Z is an illegal >>> escape sequence in a string literal. >>> The rule also allows programmers to craft input streams that denote >>> escape sequences in a string literal. For example, the input stream >>> \\\u006e results in the three characters \ \ n because the third \ is >>> eligible and thus \u006e is translated to n, while the first \ and >>> second \ are preserved as raw input characters. The three characters >>> \ \ n are subsequently interpreted in a string literal as \ n which >>> denotes the escape sequence for a linefeed. (The input stream >>> \\\u006e may also be written as \u005c\u005c\u006e.) >>> ----- >>> Alex >>> On 6/21/2021 4:41 PM, Alex Buckley wrote: >>>> There's no question that the first six raw input characters \ u 0 0 >>>> 5 c are identified as a Unicode escape \u005c and translated to a >>>> backslash. >>>> >>>> The question is whether that backslash is then treated as: >>>> >>>> 1. a raw input character \ that is followed by seven more raw input >>>> characters \ \ u 0 0 5 d?? For these *eight* raw input characters, >>>> there are three raw input character \'s in a row. Due to >>>> contiguous-\ counting, the third raw input character \ is eligible >>>> to begin a Unicode escape; the first and second pass through and you >>>> get \ \ ] which further translates within a string literal as \] >>>> >>>> or >>>> >>>> 2. something which is independent of the subsequent seven raw input >>>> characters \ \ u 0 0 5 d?? For those *seven* subsequent raw input >>>> characters, there are two raw input character \'s in a row. Due to >>>> contiguous-\ counting, the second raw input character \ is not >>>> eligible to begin a Unicode escape, so all seven raw input >>>> characters pass through. You get (including the first "independent" >>>> backslash) \ \ \ u 0 0 5 d >>>> >>>> >>>> The contiguous-\ counting is due to the fact that \\ is the escape >>>> sequence for backslash in a string literal, so we don't want too >>>> many raw \ input character to "disappear" into Unicode escapes. >>>> >>>> >>>> The JDK 15 behavior was #1. That looks correct to me. \ u 0 0 5 c >>>> becomes a raw input character \ that cannot serve as the opening >>>> backslash for an *immediate* Unicode escape (the classic JLS 3.3 >>>> scenario of \u005cu005a) but that can serve as a raw input character >>>> for the purpose of skipping over \\ pairs (the purpose of >>>> contiguous-\ counting) in order for a *later* Unicode escape to be >>>> recognized (\u005d). >>>> >>>>> Does "how many other \ characters contiguously precede it" refer to >>>>> preceding raw input characters, or does it refer to preceding >>>>> characters after unicode escape processing is performed on them? >>>> >>>> Where JLS 3.3 says "translating the ASCII characters \u followed by >>>> four hexadecimal digits to the UTF-16 code unit (?3.1) for the >>>> indicated hexadecimal value", it really means "translating the ASCII >>>> characters \u followed by four hexadecimal digits to *a raw input >>>> character which denotes* the UTF-16 code unit (?3.1) for the >>>> indicated hexadecimal value". >>>> >>>> Thus, the later clause "for each raw input character that is a >>>> backslash \, input processing must consider how many other [raw >>>> input] \ characters contiguously precede it" can be seen more easily >>>> to include characters that result from Unicode escape processing. >>>> >>>> Alex >>>> >>>> On 6/21/2021 2:56 PM, Jim Laskey wrote: >>>>> "\u005C? should have been treated as a backslash. Will check into it. >>>>> >>>>> Cheers, >>>>> >>>>> ? Jim >>>>> >>>>> ?? >>>>> >>>>>> On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon >>>>> > wrote: >>>>>> >>>>>> ? >>>>>> class T { >>>>>> ?? public static void main(String[] args) { >>>>>> ???? System.err.println("\u005C\\u005D"); >>>>>> ?? } >>>>>> } >>>>>> >>>>>> Before JDK-8254073, this prints `\]`. >>>>>> >>>>>> After JDK-8254073, unicode escape processing results in >>>>>> `\\\u005D`, which results in an 'invalid escape' error for `\u`. >>>>>> Was that deliberate? >>>>>> >>>>>> JLS 3.3 says >>>>>> >>>>>>> for each raw input character that is a backslash \, input >>>>>>> processing must consider how many other \ characters contiguously >>>>>>> precede it, separating it from a non-\ character or the start of >>>>>>> the input stream. If this number is even, then the \ is eligible >>>>>>> to begin a Unicode escape; if the number is odd, then the \ is >>>>>>> not eligible to begin a Unicode escape. >>>>>> >>>>>> The difference is in whether `\u005C` (the unicode escape for `\`) >>>>>> counts as one of the `\` preceding a valid unicode escape. >>>>>> >>>>>> Does "how many other \ characters contiguously precede it" refer >>>>>> to preceding raw input characters, or does it refer to preceding >>>>>> characters after unicode escape processing is performed on them? >>>>>> >>>>>> JLS 3.3 also mentions that a "character produced by a Unicode >>>>>> escape does not participate in further Unicode escapes", but I'm >>>>>> not sure if that applies here, since in the pre-JDK-8254073 >>>>>> interpretation the unicode-escaped backslash isn't really >>>>>> 'participating' in the second unicode escape. >>>>>> >>>>>> Thanks, >>>>>> Liam > From jlahoda at openjdk.java.net Wed Jul 7 06:08:13 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 06:08:13 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v7] In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: > Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`. > > How does this look? Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/81/files - new: https://git.openjdk.java.net/jdk17/pull/81/files/ca79b2bd..469254a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81 PR: https://git.openjdk.java.net/jdk17/pull/81 From jlahoda at openjdk.java.net Wed Jul 7 06:28:53 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 06:28:53 GMT Subject: [jdk17] Integrated: 8269802: javac fails to compile nested pattern matching switches In-Reply-To: <-nGpz8-kJwEKwA-NHMb6I7PFpV_zvLnTc-OELN3s5kU=.2e33bae4-57ee-4b2e-9b8d-3bd329ff1b5c@github.com> References: <-nGpz8-kJwEKwA-NHMb6I7PFpV_zvLnTc-OELN3s5kU=.2e33bae4-57ee-4b2e-9b8d-3bd329ff1b5c@github.com> Message-ID: On Fri, 2 Jul 2021 13:19:08 GMT, Jan Lahoda wrote: > There are two places which where `TransPatterns` is mistakenly not translating a subtree: the statements for non-pattern cases, and the selector. This PR is fixing that by translating the statements and selector. This pull request has now been integrated. Changeset: 815e4af3 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk17/commit/815e4af35d29d0d5606281d36d4ef72b756d38cc Stats: 124 lines in 2 files changed: 123 ins; 0 del; 1 mod 8269802: javac fails to compile nested pattern matching switches 8269808: javac generates class with invalid stack map Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk17/pull/203 From ilyas.selimov at jetbrains.com Wed Jul 7 07:17:41 2021 From: ilyas.selimov at jetbrains.com (Ilyas Selimov) Date: Wed, 7 Jul 2021 14:17:41 +0700 Subject: Pattern matching for switch: Spec and Javac inconsistency regarding enhanced switch statements Message-ID: Hello! I found a difference between completeness rules for enhanced switch statements in spec draft ( http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210527/specs/patterns-switch-jls.html#jls-14.11.2 ) and its javac implementation (OpenJDK 17 build 17-ea+29-2576). > An enhanced switch statement is one where either (i) the type of the selector expression is not char, byte, short, int, Character, Byte, Short, Integer, String, or an enum type, or (ii) at least one of the switch labels has a pattern case label element or a null case label element. According to the statement, the next switch statement is enhanced: void test(String s) { switch (s) { case null: break; } } > If the switch statement is an enhanced switch statement, then the switch block must be complete for the selector expression. As one contains neither total pattern, nor default label, it's incomplete, but javac compiles it correctly. Maybe I missed PR that fixed the issue. Thanks, Ilyas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.java.net Wed Jul 7 07:29:51 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 07:29:51 GMT Subject: [jdk17] Integrated: 8268859: jshell throws exception while parsing illegal "case true" In-Reply-To: <_vtnRjce-_cQvI8ObT24pGzzLjZAnjJ6zY02GneyFtk=.126743f3-7e5e-4397-85d0-0b5bc34edfb9@github.com> References: <_vtnRjce-_cQvI8ObT24pGzzLjZAnjJ6zY02GneyFtk=.126743f3-7e5e-4397-85d0-0b5bc34edfb9@github.com> Message-ID: On Fri, 2 Jul 2021 12:11:52 GMT, Jan Lahoda wrote: > Currently, broken case labels like `case true t` parse as patterns, whose type is `true`, which then fails later during annotation handling. This patch is trying to improve (and fix) the pattern/expression disambiguation again, making it more explicit than before. With this patch, only labels that begin with ` ` should be considered patterns. > > The recently added no-preview part of `SwitchErrors` is moved to `PatternErrorRecovery.java`, because that indeed turned out to be difficult to maintain. This pull request has now been integrated. Changeset: 820f2900 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk17/commit/820f2900d8650609d737d83141e91adc93daadf7 Stats: 548 lines in 12 files changed: 279 ins; 206 del; 63 mod 8268859: jshell throws exception while parsing illegal "case true" Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk17/pull/202 From jlahoda at openjdk.java.net Wed Jul 7 07:37:20 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 07:37:20 GMT Subject: [jdk17] RFR: 8266036: class file for sun.misc.Contended not found [v3] In-Reply-To: References: Message-ID: > [this is an improved version of openjdk/jdk PR: > https://github.com/openjdk/jdk/pull/4428 > ] > > The ct.sym may contain classfiles referring to annotations that are not present in ct.sym (liek JDK's internal annotation sun.misc.Contended). If javac will try to load them (while discovering annotations for the purpose of detecting which annotation processors should be run), an error will be produced (please see the issue). The proposal is to strip annotations that are not present in ct.sym when generating ct.sym. > > As noted by @jddarcy, we also need a special handling of ValueBased, which this patch should do, so it also solves https://bugs.openjdk.java.net/browse/JDK-8258421 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/27/files - new: https://git.openjdk.java.net/jdk17/pull/27/files/187ad580..ed26b697 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=27&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=27&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/27/head:pull/27 PR: https://git.openjdk.java.net/jdk17/pull/27 From jan.lahoda at oracle.com Wed Jul 7 08:04:55 2021 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 7 Jul 2021 10:04:55 +0200 Subject: Pattern matching for switch: Spec and Javac inconsistency regarding enhanced switch statements In-Reply-To: References: Message-ID: <90958bdd-8a6c-6545-9dd7-ad45af855e6a@oracle.com> Thanks Ilyas. I've filled: https://bugs.openjdk.java.net/browse/JDK-8270006 Jan On 07. 07. 21 9:17, Ilyas Selimov wrote: > Hello! > > I found a difference between completeness rules for enhanced switch > statements in spec draft > (http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210527/specs/patterns-switch-jls.html#jls-14.11.2 > ) > > and its javac implementation (OpenJDK 17 build 17-ea+29-2576). > > > An enhanced switch statement is one where either (i) the type of the > selector expression is not char, byte, short, int, Character, Byte, > Short, Integer, String, or an enum type, > or (ii) at least one of the switch labels has a pattern case label > element or a null case label element. > > According to the statement, the next switch statement is enhanced: > void test(String s) { > ? switch (s) { > ? ? case null: > ? ? ? break; > ? } > } > > > If the switch statement is an enhanced switch statement, then the > switch block must be complete for the selector expression. > > As one contains neither total pattern, nor default label, it's > incomplete, but javac compiles it correctly. > Maybe I missed PR that fixed the issue. > > Thanks, > Ilyas From mcimadamore at openjdk.java.net Wed Jul 7 09:46:52 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 7 Jul 2021 09:46:52 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v7] In-Reply-To: References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: <4qlXx3Wr0P_28ZEfODwiLKdkiyBm9c6Zqg6J5SV4Nzk=.23c35dee-de62-4514-b07d-8ef1024cb9e6@github.com> On Wed, 7 Jul 2021 06:08:13 GMT, Jan Lahoda wrote: >> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`. >> >> How does this look? > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> Marked as reviewed by mcimadamore (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/81 From jlahoda at openjdk.java.net Wed Jul 7 09:52:59 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 09:52:59 GMT Subject: [jdk17] Integrated: 8266036: class file for sun.misc.Contended not found In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 13:09:55 GMT, Jan Lahoda wrote: > [this is an improved version of openjdk/jdk PR: > https://github.com/openjdk/jdk/pull/4428 > ] > > The ct.sym may contain classfiles referring to annotations that are not present in ct.sym (liek JDK's internal annotation sun.misc.Contended). If javac will try to load them (while discovering annotations for the purpose of detecting which annotation processors should be run), an error will be produced (please see the issue). The proposal is to strip annotations that are not present in ct.sym when generating ct.sym. > > As noted by @jddarcy, we also need a special handling of ValueBased, which this patch should do, so it also solves https://bugs.openjdk.java.net/browse/JDK-8258421 This pull request has now been integrated. Changeset: 7fcd5ca0 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk17/commit/7fcd5ca0258b1dc6c34c98ced177ee4dc7945f26 Stats: 325 lines in 15 files changed: 215 ins; 16 del; 94 mod 8266036: class file for sun.misc.Contended not found 8258421: (jdeprscan) tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java failed with "error: cannot access jdk.internal.ValueBased" Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk17/pull/27 From jlahoda at openjdk.java.net Wed Jul 7 11:52:03 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 11:52:03 GMT Subject: [jdk17] RFR: 8270006: Switches with 'case null:' should be exhaustive Message-ID: <677k9MGWYUT8ESdb21tYEUWywvxfMFtTWd6HOA--htM=.e061e538-82ce-4222-9137-30041722893a@github.com> Code like: void exhaustiveAndNull(String s) { switch (s) { case null: break; } } should be rejected, because the switch is no exhaustive, but it is a "new" switch. (Note that this not a problem for switch expressions, which always have to be exhaustive.) ------------- Commit messages: - 8270006: Switches with 'case null:' should be exhaustive Changes: https://git.openjdk.java.net/jdk17/pull/224/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=224&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270006 Stats: 13 lines in 3 files changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/224.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/224/head:pull/224 PR: https://git.openjdk.java.net/jdk17/pull/224 From jlahoda at openjdk.java.net Wed Jul 7 12:10:16 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 12:10:16 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v8] In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: > Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`. > > How does this look? Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: If the pattern type is a supertype of the selector type, use selector type rather than the pattern type when constructing the bootstrap method parameters. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/81/files - new: https://git.openjdk.java.net/jdk17/pull/81/files/469254a4..d970402e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=06-07 Stats: 30 lines in 2 files changed: 27 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81 PR: https://git.openjdk.java.net/jdk17/pull/81 From jlahoda at openjdk.java.net Wed Jul 7 12:36:52 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 12:36:52 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v8] In-Reply-To: References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: On Wed, 7 Jul 2021 12:10:16 GMT, Jan Lahoda wrote: >> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`. >> >> How does this look? > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > If the pattern type is a supertype of the selector type, use selector type rather than the pattern type when constructing the bootstrap method parameters. There turned out to be a bug in the patch: considering a switch over enum like: E e = ...; switch (e) { case Object o -> {} } (Or, even worse, `case Object o && ->`), the patch will generate `Object.class` as a static parameter to the `enumSwitch` bootstrap method. But the method (rightfully) requires the enum class as the static parameter. https://github.com/openjdk/jdk17/pull/81/commits/d970402e969d76a017cdfdcbc6556f6d9a9f3bfa tweaks the code generation to produce `E.class` instead of `Object.class`. ------------- PR: https://git.openjdk.java.net/jdk17/pull/81 From forax at openjdk.java.net Wed Jul 7 12:40:51 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 7 Jul 2021 12:40:51 GMT Subject: [jdk17] RFR: 8270006: Switches with 'case null:' should be exhaustive In-Reply-To: <677k9MGWYUT8ESdb21tYEUWywvxfMFtTWd6HOA--htM=.e061e538-82ce-4222-9137-30041722893a@github.com> References: <677k9MGWYUT8ESdb21tYEUWywvxfMFtTWd6HOA--htM=.e061e538-82ce-4222-9137-30041722893a@github.com> Message-ID: On Wed, 7 Jul 2021 11:45:11 GMT, Jan Lahoda wrote: > Code like: > > void exhaustiveAndNull(String s) { > switch (s) { > case null: break; > } > } > > > should be rejected, because the switch is no exhaustive, but it is a "new" switch. (Note that this not a problem for switch expressions, which always have to be exhaustive.) test/langtools/tools/javac/patterns/SwitchErrors.java line 192: > 190: case null: break; > 191: } > 192: } The other possible new syntax is "case default", but there is no error because it's exhaustive. void exhaustiveCaseDefaultNoError(String s) { switch (s) { case default: break; } } ------------- PR: https://git.openjdk.java.net/jdk17/pull/224 From vromero at openjdk.java.net Wed Jul 7 15:05:49 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 7 Jul 2021 15:05:49 GMT Subject: [jdk17] RFR: 8270006: Switches with 'case null:' should be exhaustive In-Reply-To: <677k9MGWYUT8ESdb21tYEUWywvxfMFtTWd6HOA--htM=.e061e538-82ce-4222-9137-30041722893a@github.com> References: <677k9MGWYUT8ESdb21tYEUWywvxfMFtTWd6HOA--htM=.e061e538-82ce-4222-9137-30041722893a@github.com> Message-ID: On Wed, 7 Jul 2021 11:45:11 GMT, Jan Lahoda wrote: > Code like: > > void exhaustiveAndNull(String s) { > switch (s) { > case null: break; > } > } > > > should be rejected, because the switch is no exhaustive, but it is a "new" switch. (Note that this not a problem for switch expressions, which always have to be exhaustive.) lgtm ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/224 From jlahoda at openjdk.java.net Wed Jul 7 16:15:49 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 16:15:49 GMT Subject: RFR: 8269113: Javac throws when compiling switch (null) In-Reply-To: References: Message-ID: On Sun, 4 Jul 2021 18:13:26 GMT, Guoxiong Li wrote: > Hi all, > > When we use `switch(null)` in the source code, the type of the selector is `BottomType`. > So the statement `Type seltype = selector.type;` of the method `TransPatterns::handleSwitch` will get a `BottomType`. > Then compiler mistakenly uses this `BottomType` to construct a new `VarSymbol`. > > > VarSymbol temp = new VarSymbol(Flags.SYNTHETIC, > names.fromString("selector" + tree.pos + target.syntheticNameChar() + "temp"), > seltype, // <--------here is a BottomType > currentMethodSym); > > > At last, when the compiler uses the new `VarSymbol temp` to construct a new `JCVariableDecl`(the code shown as below), it crashes at the method `TreeMaker::Type` because the method `TreeMaker::Type` can't handle the type `BottomType`. > > > statements.append(make.at(tree.pos).VarDef(temp, !hasNullCase ? attr.makeNullCheck(selector) > : selector)); > > > This patch changes the type from `BottomType` to `syms.objectType` and adds the corresponding test. > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Looks good to me. Might make sense to submit against openjdk/jdk17 and integrate there? ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4679 From gli at openjdk.java.net Wed Jul 7 16:29:50 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 7 Jul 2021 16:29:50 GMT Subject: RFR: 8269113: Javac throws when compiling switch (null) In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 16:12:51 GMT, Jan Lahoda wrote: >> Hi all, >> >> When we use `switch(null)` in the source code, the type of the selector is `BottomType`. >> So the statement `Type seltype = selector.type;` of the method `TransPatterns::handleSwitch` will get a `BottomType`. >> Then compiler mistakenly uses this `BottomType` to construct a new `VarSymbol`. >> >> >> VarSymbol temp = new VarSymbol(Flags.SYNTHETIC, >> names.fromString("selector" + tree.pos + target.syntheticNameChar() + "temp"), >> seltype, // <--------here is a BottomType >> currentMethodSym); >> >> >> At last, when the compiler uses the new `VarSymbol temp` to construct a new `JCVariableDecl`(the code shown as below), it crashes at the method `TreeMaker::Type` because the method `TreeMaker::Type` can't handle the type `BottomType`. >> >> >> statements.append(make.at(tree.pos).VarDef(temp, !hasNullCase ? attr.makeNullCheck(selector) >> : selector)); >> >> >> This patch changes the type from `BottomType` to `syms.objectType` and adds the corresponding test. >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Looks good to me. Might make sense to submit against openjdk/jdk17 and integrate there? @lahodaj thanks for your review. I will move this patch to JDK 17 later. ------------- PR: https://git.openjdk.java.net/jdk/pull/4679 From jlahoda at openjdk.java.net Wed Jul 7 16:37:51 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 16:37:51 GMT Subject: RFR: 8269113: Javac throws when compiling switch (null) In-Reply-To: References: Message-ID: On Sun, 4 Jul 2021 18:13:26 GMT, Guoxiong Li wrote: > Hi all, > > When we use `switch(null)` in the source code, the type of the selector is `BottomType`. > So the statement `Type seltype = selector.type;` of the method `TransPatterns::handleSwitch` will get a `BottomType`. > Then compiler mistakenly uses this `BottomType` to construct a new `VarSymbol`. > > > VarSymbol temp = new VarSymbol(Flags.SYNTHETIC, > names.fromString("selector" + tree.pos + target.syntheticNameChar() + "temp"), > seltype, // <--------here is a BottomType > currentMethodSym); > > > At last, when the compiler uses the new `VarSymbol temp` to construct a new `JCVariableDecl`(the code shown as below), it crashes at the method `TreeMaker::Type` because the method `TreeMaker::Type` can't handle the type `BottomType`. > > > statements.append(make.at(tree.pos).VarDef(temp, !hasNullCase ? attr.makeNullCheck(selector) > : selector)); > > > This patch changes the type from `BottomType` to `syms.objectType` and adds the corresponding test. > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong I am sorry, but it may not be so simple. I apologize for that, I need to do some more investigations, sorry. ------------- PR: https://git.openjdk.java.net/jdk/pull/4679 From mcimadamore at openjdk.java.net Wed Jul 7 16:39:49 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 7 Jul 2021 16:39:49 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v8] In-Reply-To: References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: On Wed, 7 Jul 2021 12:10:16 GMT, Jan Lahoda wrote: >> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`. >> >> How does this look? > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > If the pattern type is a supertype of the selector type, use selector type rather than the pattern type when constructing the bootstrap method parameters. Good catch - should we also add test for when an enum implements an interface? enum Foo implements A { ... } Foo foo = ... switch(foo) { case A a: ... } I think the patch you have should work since you are using subtyping. Another thing to consider: should we be worried about type erasure turning the selector type into some weird, unexpected type? I don't think that should be the case, given that if a type variable has a bound E, where E is an enum, the erasure should always be E (as E is a "class" type, so should win, even in intersections). ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/81 From gli at openjdk.java.net Wed Jul 7 16:52:51 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 7 Jul 2021 16:52:51 GMT Subject: RFR: 8269113: Javac throws when compiling switch (null) In-Reply-To: References: Message-ID: On Sun, 4 Jul 2021 18:13:26 GMT, Guoxiong Li wrote: > Hi all, > > When we use `switch(null)` in the source code, the type of the selector is `BottomType`. > So the statement `Type seltype = selector.type;` of the method `TransPatterns::handleSwitch` will get a `BottomType`. > Then compiler mistakenly uses this `BottomType` to construct a new `VarSymbol`. > > > VarSymbol temp = new VarSymbol(Flags.SYNTHETIC, > names.fromString("selector" + tree.pos + target.syntheticNameChar() + "temp"), > seltype, // <--------here is a BottomType > currentMethodSym); > > > At last, when the compiler uses the new `VarSymbol temp` to construct a new `JCVariableDecl`(the code shown as below), it crashes at the method `TreeMaker::Type` because the method `TreeMaker::Type` can't handle the type `BottomType`. > > > statements.append(make.at(tree.pos).VarDef(temp, !hasNullCase ? attr.makeNullCheck(selector) > : selector)); > > > This patch changes the type from `BottomType` to `syms.objectType` and adds the corresponding test. > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Never mind. I will continue to contact or assist you in this PR. If the final patch is not large, it could be moved to JDK 17 at last. ------------- PR: https://git.openjdk.java.net/jdk/pull/4679 From jlahoda at openjdk.java.net Wed Jul 7 17:18:53 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 17:18:53 GMT Subject: [jdk17] RFR: 8270006: Switches with 'case null:' should be exhaustive In-Reply-To: References: <677k9MGWYUT8ESdb21tYEUWywvxfMFtTWd6HOA--htM=.e061e538-82ce-4222-9137-30041722893a@github.com> Message-ID: On Wed, 7 Jul 2021 12:37:46 GMT, R?mi Forax wrote: >> Code like: >> >> void exhaustiveAndNull(String s) { >> switch (s) { >> case null: break; >> } >> } >> >> >> should be rejected, because the switch is no exhaustive, but it is a "new" switch. (Note that this not a problem for switch expressions, which always have to be exhaustive.) > > test/langtools/tools/javac/patterns/SwitchErrors.java line 192: > >> 190: case null: break; >> 191: } >> 192: } > > The other possible new syntax is "case default", but there is no error because it's exhaustive. > > > void exhaustiveCaseDefaultNoError(String s) { > switch (s) { > case default: break; > } > } Correct, there are tests that verify (at least as a side-effect) that `case default` is total in `test/langtools/tools/javac/patterns/CaseDefault.java`. ------------- PR: https://git.openjdk.java.net/jdk17/pull/224 From forax at univ-mlv.fr Wed Jul 7 17:42:32 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 7 Jul 2021 19:42:32 +0200 (CEST) Subject: Error messages technically true but that does not help if several cases have the same erasure Message-ID: <1080252499.2379333.1625679752072.JavaMail.zimbra@u-pem.fr> When compiling this code: Object o = ""; switch (o) { case List l -> System.out.println("list2"); case List l -> System.out.println("list1"); default -> System.out.println("default"); } I get PatternMatchingWrongDominated.java:8: error: this case label is dominated by a preceding case label case List l -> System.out.println("list1"); ^ instead of an error saying that two cases have the same erasure. The funny thing, is that permuting the two first cases give the same result. The same is true for List list = null; switch (list) { case List l -> System.out.println("list2"); case List l -> System.out.println("list1"); } which reports PatternMatchingWrongDominated.java:18: error: duplicate total pattern case List l -> System.out.println("list1"); ^ I think javac should have a specific error if two cases have the same erasure. regards, R?mi From vromero at openjdk.java.net Wed Jul 7 18:54:50 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 7 Jul 2021 18:54:50 GMT Subject: RFR: 8269738: AssertionError when combining pattern maching and function closure In-Reply-To: References: Message-ID: On Sat, 3 Jul 2021 19:27:34 GMT, Guoxiong Li wrote: > Hi all, > > The method `TransPatterns.BasicBindingContext::bindingDeclared` uses `varSymbol.owner` to construct a new `VarSymbol`. > > > res = new VarSymbol(varSymbol.flags(), varSymbol.name, varSymbol.type, varSymbol.owner); > > > But the `varSymbol.owner` may be also a `VarSymbol` when it is at the `init` clause of the static variables or instance variables. > You can see the following code. The `owner` of the `Interger i` is `staticNum1` or `instanceNum1` which is `VarSymbol`. > > > static Number num1 = 1; > static Number staticNum1 = (num1 instanceof Integer i) ? ((Supplier) () -> i).get() : null; > Number instanceNum1 = (num1 instanceof Integer i) ? ((Supplier) () -> i).get() : null; > > > Then, the class `LambdaToMethod` can't capture the expected variables `Integer i` and the following phases such as `Gen` may fail or throw exceptions. > > This patch uses the `currentMethodSym` which means a class or instance field initializer to replace `varSymbol.owner` and adds the corresponding test. > > --- > > And I have a problem: > >> The `owner` of the `Interger i` is `staticNum1` or `instanceNum1` which is `VarSymbol`. > > The statement above means the `env.info.scope.owner` in the method `Attr::visitBindingPattern` is a `VarSymbol`. Is it a expected result? Or the original `env.info.scope.owner` should be modified to a class or instance field initializer which the following phases need. > > > // Attr.java > public void visitBindingPattern(JCBindingPattern tree) { > ...... > BindingSymbol v = new BindingSymbol(tree.var.mods.flags, tree.var.name, tree.var.vartype.type, env.info.scope.owner); > ...... > } > > > --- > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong lgtm ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4678 From vromero at openjdk.java.net Wed Jul 7 19:59:33 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 7 Jul 2021 19:59:33 GMT Subject: RFR: 8261006: 'super' qualified method references cannot occur in a static context [v6] In-Reply-To: References: Message-ID: > Please review this PR, currently javac is accepting code like: > > > import java.util.function.Supplier; > > public class MethodReferenceInConstructorInvocation { > interface Bar { > default String getString() { return ""; } > } > > static class Foo implements Bar { > public Foo() { this(Bar.super::getString); } > public Foo(Supplier sString) {} > } > } > > > but the spec states in `15.13 Method Reference Expressions`: > > If a method reference expression has the form super :: [TypeArguments] Identifier > or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if > the expression occurs in a static context (?8.1.3). > > and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context. > > TIA Vicente Romero 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 six additional commits since the last revision: - Merge branch 'master' into JDK-8261006 - addressing review comments - updating comment - addressing review comments - Merge branch 'master' into JDK-8261006 - 8261006: fail to parse broken interface::method in lambda ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4376/files - new: https://git.openjdk.java.net/jdk/pull/4376/files/d728b8be..cdb5c3fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4376&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4376&range=04-05 Stats: 28605 lines in 572 files changed: 11409 ins; 14677 del; 2519 mod Patch: https://git.openjdk.java.net/jdk/pull/4376.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4376/head:pull/4376 PR: https://git.openjdk.java.net/jdk/pull/4376 From jwilhelm at openjdk.java.net Thu Jul 8 00:09:13 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 8 Jul 2021 00:09:13 GMT Subject: RFR: Merge jdk17 Message-ID: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com> Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8269929: (test) Add diagnostic info to ProceessBuilder/Basic.java for unexpected output - 8269185: Directories in /opt/runtimepackagetest and /path/to/jdk-17 are different - 8269879: [PPC64] C2: Math.rint intrinsic uses wrong rounding mode - 8266036: class file for sun.misc.Contended not found - 8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available" - 8268859: jshell throws exception while parsing illegal "case true" - 8269802: javac fails to compile nested pattern matching switches - 8269830: SA's vm object vtable matching code sometimes matches on incorrect type - 8268778: CDS check_excluded_classes needs DumpTimeTable_lock The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4713&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4713&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4713/files Stats: 1083 lines in 36 files changed: 629 ins; 278 del; 176 mod Patch: https://git.openjdk.java.net/jdk/pull/4713.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4713/head:pull/4713 PR: https://git.openjdk.java.net/jdk/pull/4713 From jwilhelm at openjdk.java.net Thu Jul 8 01:01:08 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 8 Jul 2021 01:01:08 GMT Subject: Integrated: Merge jdk17 In-Reply-To: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com> References: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com> Message-ID: On Thu, 8 Jul 2021 00:01:43 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 270fbcb3 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/270fbcb3f5755baf045fa6dec3fba459d32c32e1 Stats: 1083 lines in 36 files changed: 629 ins; 278 del; 176 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4713 From jwilhelm at openjdk.java.net Thu Jul 8 01:01:07 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 8 Jul 2021 01:01:07 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com> References: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com> Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 180 commits: - Merge - 8264735: Make dynamic dump repeatable Reviewed-by: ccheung, iklam - 8269481: SctpMultiChannel never releases own file descriptor Reviewed-by: alanb, chegar - 8270027: ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64 Reviewed-by: mgronlun - 8267303: Replace MinObjectAlignmentSize usages for non-Java heap objects Reviewed-by: kbarrett, tschatzl, minqi - 8268635: Corrupt oop in ClassLoaderData Reviewed-by: iklam, dholmes - 8269923: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java failed with "FATAL ERROR in native method: Primitive type array expected but not received for JNI array operation" Reviewed-by: dcubed, dholmes - 8269761: idea.sh missing .exe suffix when invoking javac on WSL Reviewed-by: mcimadamore, erikj - 8269294: Verify_before/after_young_collection should execute all verification Reviewed-by: iwalulya, kbarrett - 8269908: Move MemoryService::track_memory_usage call into G1MonitoringScope Reviewed-by: ayang, kbarrett - ... and 170 more: https://git.openjdk.java.net/jdk/compare/c812bbbe...e5695159 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4713/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4713&range=01 Stats: 46991 lines in 850 files changed: 21189 ins; 22881 del; 2921 mod Patch: https://git.openjdk.java.net/jdk/pull/4713.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4713/head:pull/4713 PR: https://git.openjdk.java.net/jdk/pull/4713 From gli at openjdk.java.net Thu Jul 8 02:35:49 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 8 Jul 2021 02:35:49 GMT Subject: RFR: 8269738: AssertionError when combining pattern matching and function closure In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 18:51:52 GMT, Vicente Romero wrote: >> Hi all, >> >> The method `TransPatterns.BasicBindingContext::bindingDeclared` uses `varSymbol.owner` to construct a new `VarSymbol`. >> >> >> res = new VarSymbol(varSymbol.flags(), varSymbol.name, varSymbol.type, varSymbol.owner); >> >> >> But the `varSymbol.owner` may be also a `VarSymbol` when it is at the `init` clause of the static variables or instance variables. >> You can see the following code. The `owner` of the `Interger i` is `staticNum1` or `instanceNum1` which is `VarSymbol`. >> >> >> static Number num1 = 1; >> static Number staticNum1 = (num1 instanceof Integer i) ? ((Supplier) () -> i).get() : null; >> Number instanceNum1 = (num1 instanceof Integer i) ? ((Supplier) () -> i).get() : null; >> >> >> Then, the class `LambdaToMethod` can't capture the expected variables `Integer i` and the following phases such as `Gen` may fail or throw exceptions. >> >> This patch uses the `currentMethodSym` which means a class or instance field initializer to replace `varSymbol.owner` and adds the corresponding test. >> >> --- >> >> And I have a problem: >> >>> The `owner` of the `Interger i` is `staticNum1` or `instanceNum1` which is `VarSymbol`. >> >> The statement above means the `env.info.scope.owner` in the method `Attr::visitBindingPattern` is a `VarSymbol`. Is it a expected result? Or the original `env.info.scope.owner` should be modified to a class or instance field initializer which the following phases need. >> >> >> // Attr.java >> public void visitBindingPattern(JCBindingPattern tree) { >> ...... >> BindingSymbol v = new BindingSymbol(tree.var.mods.flags, tree.var.name, tree.var.vartype.type, env.info.scope.owner); >> ...... >> } >> >> >> --- >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > lgtm @vicente-romero-oracle Thanks for your review. Should we raise this bug to `P3` and fix it in JDK 17? ------------- PR: https://git.openjdk.java.net/jdk/pull/4678 From vromero at openjdk.java.net Thu Jul 8 03:49:48 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 8 Jul 2021 03:49:48 GMT Subject: RFR: 8269738: AssertionError when combining pattern matching and function closure In-Reply-To: References: Message-ID: <01QX7-KwdmLdKwxpnvn6jSPEYa4v90agpy-jY-FMqxc=.e32bfb93-83d9-482d-a9b4-29886bd7db4a@github.com> On Wed, 7 Jul 2021 18:51:52 GMT, Vicente Romero wrote: >> Hi all, >> >> The method `TransPatterns.BasicBindingContext::bindingDeclared` uses `varSymbol.owner` to construct a new `VarSymbol`. >> >> >> res = new VarSymbol(varSymbol.flags(), varSymbol.name, varSymbol.type, varSymbol.owner); >> >> >> But the `varSymbol.owner` may be also a `VarSymbol` when it is at the `init` clause of the static variables or instance variables. >> You can see the following code. The `owner` of the `Interger i` is `staticNum1` or `instanceNum1` which is `VarSymbol`. >> >> >> static Number num1 = 1; >> static Number staticNum1 = (num1 instanceof Integer i) ? ((Supplier) () -> i).get() : null; >> Number instanceNum1 = (num1 instanceof Integer i) ? ((Supplier) () -> i).get() : null; >> >> >> Then, the class `LambdaToMethod` can't capture the expected variables `Integer i` and the following phases such as `Gen` may fail or throw exceptions. >> >> This patch uses the `currentMethodSym` which means a class or instance field initializer to replace `varSymbol.owner` and adds the corresponding test. >> >> --- >> >> And I have a problem: >> >>> The `owner` of the `Interger i` is `staticNum1` or `instanceNum1` which is `VarSymbol`. >> >> The statement above means the `env.info.scope.owner` in the method `Attr::visitBindingPattern` is a `VarSymbol`. Is it a expected result? Or the original `env.info.scope.owner` should be modified to a class or instance field initializer which the following phases need. >> >> >> // Attr.java >> public void visitBindingPattern(JCBindingPattern tree) { >> ...... >> BindingSymbol v = new BindingSymbol(tree.var.mods.flags, tree.var.name, tree.var.vartype.type, env.info.scope.owner); >> ...... >> } >> >> >> --- >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > lgtm > @vicente-romero-oracle Thanks for your review. Should we raise this bug to `P3` and fix it in JDK 17? yep, it makes sense to do it ------------- PR: https://git.openjdk.java.net/jdk/pull/4678 From gli at openjdk.java.net Thu Jul 8 04:34:51 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 8 Jul 2021 04:34:51 GMT Subject: RFR: 8269738: AssertionError when combining pattern matching and function closure In-Reply-To: References: Message-ID: <3VDhFEs4j2YgwXK-nnTtkJLOy5tRwVv7Vxec7b535F0=.d93d5975-fb6b-41f1-994d-9c1e20ac81af@github.com> On Sat, 3 Jul 2021 19:27:34 GMT, Guoxiong Li wrote: > Hi all, > > The method `TransPatterns.BasicBindingContext::bindingDeclared` uses `varSymbol.owner` to construct a new `VarSymbol`. > > > res = new VarSymbol(varSymbol.flags(), varSymbol.name, varSymbol.type, varSymbol.owner); > > > But the `varSymbol.owner` may be also a `VarSymbol` when it is at the `init` clause of the static variables or instance variables. > You can see the following code. The `owner` of the `Interger i` is `staticNum1` or `instanceNum1` which is `VarSymbol`. > > > static Number num1 = 1; > static Number staticNum1 = (num1 instanceof Integer i) ? ((Supplier) () -> i).get() : null; > Number instanceNum1 = (num1 instanceof Integer i) ? ((Supplier) () -> i).get() : null; > > > Then, the class `LambdaToMethod` can't capture the expected variables `Integer i` and the following phases such as `Gen` may fail or throw exceptions. > > This patch uses the `currentMethodSym` which means a class or instance field initializer to replace `varSymbol.owner` and adds the corresponding test. > > --- > > And I have a problem: > >> The `owner` of the `Interger i` is `staticNum1` or `instanceNum1` which is `VarSymbol`. > > The statement above means the `env.info.scope.owner` in the method `Attr::visitBindingPattern` is a `VarSymbol`. Is it a expected result? Or the original `env.info.scope.owner` should be modified to a class or instance field initializer which the following phases need. > > > // Attr.java > public void visitBindingPattern(JCBindingPattern tree) { > ...... > BindingSymbol v = new BindingSymbol(tree.var.mods.flags, tree.var.name, tree.var.vartype.type, env.info.scope.owner); > ...... > } > > > --- > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Moving to JDK 17. Please see [jdk17/pull/230](https://github.com/openjdk/jdk17/pull/230). ------------- PR: https://git.openjdk.java.net/jdk/pull/4678 From gli at openjdk.java.net Thu Jul 8 04:34:52 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 8 Jul 2021 04:34:52 GMT Subject: Withdrawn: 8269738: AssertionError when combining pattern matching and function closure In-Reply-To: References: Message-ID: On Sat, 3 Jul 2021 19:27:34 GMT, Guoxiong Li wrote: > Hi all, > > The method `TransPatterns.BasicBindingContext::bindingDeclared` uses `varSymbol.owner` to construct a new `VarSymbol`. > > > res = new VarSymbol(varSymbol.flags(), varSymbol.name, varSymbol.type, varSymbol.owner); > > > But the `varSymbol.owner` may be also a `VarSymbol` when it is at the `init` clause of the static variables or instance variables. > You can see the following code. The `owner` of the `Interger i` is `staticNum1` or `instanceNum1` which is `VarSymbol`. > > > static Number num1 = 1; > static Number staticNum1 = (num1 instanceof Integer i) ? ((Supplier) () -> i).get() : null; > Number instanceNum1 = (num1 instanceof Integer i) ? ((Supplier) () -> i).get() : null; > > > Then, the class `LambdaToMethod` can't capture the expected variables `Integer i` and the following phases such as `Gen` may fail or throw exceptions. > > This patch uses the `currentMethodSym` which means a class or instance field initializer to replace `varSymbol.owner` and adds the corresponding test. > > --- > > And I have a problem: > >> The `owner` of the `Interger i` is `staticNum1` or `instanceNum1` which is `VarSymbol`. > > The statement above means the `env.info.scope.owner` in the method `Attr::visitBindingPattern` is a `VarSymbol`. Is it a expected result? Or the original `env.info.scope.owner` should be modified to a class or instance field initializer which the following phases need. > > > // Attr.java > public void visitBindingPattern(JCBindingPattern tree) { > ...... > BindingSymbol v = new BindingSymbol(tree.var.mods.flags, tree.var.name, tree.var.vartype.type, env.info.scope.owner); > ...... > } > > > --- > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4678 From gli at openjdk.java.net Thu Jul 8 04:36:06 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 8 Jul 2021 04:36:06 GMT Subject: [jdk17] RFR: 8269738: AssertionError when combining pattern matching and function closure Message-ID: This is a duplicated PR of the [jdk/pull/4678](https://github.com/openjdk/jdk/pull/4678). ------------- Commit messages: - 8269738: AssertionError when combining pattern matching and function closure Changes: https://git.openjdk.java.net/jdk17/pull/230/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=230&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269738 Stats: 20 lines in 2 files changed: 18 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/230.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/230/head:pull/230 PR: https://git.openjdk.java.net/jdk17/pull/230 From jlahoda at openjdk.java.net Thu Jul 8 08:06:55 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 8 Jul 2021 08:06:55 GMT Subject: [jdk17] Integrated: 8270006: Switches with 'case null:' should be exhaustive In-Reply-To: <677k9MGWYUT8ESdb21tYEUWywvxfMFtTWd6HOA--htM=.e061e538-82ce-4222-9137-30041722893a@github.com> References: <677k9MGWYUT8ESdb21tYEUWywvxfMFtTWd6HOA--htM=.e061e538-82ce-4222-9137-30041722893a@github.com> Message-ID: On Wed, 7 Jul 2021 11:45:11 GMT, Jan Lahoda wrote: > Code like: > > void exhaustiveAndNull(String s) { > switch (s) { > case null: break; > } > } > > > should be rejected, because the switch is no exhaustive, but it is a "new" switch. (Note that this not a problem for switch expressions, which always have to be exhaustive.) This pull request has now been integrated. Changeset: 4f707591 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk17/commit/4f707591754e5e7f747d1d0a47f78f49060771c2 Stats: 13 lines in 3 files changed: 10 ins; 0 del; 3 mod 8270006: Switches with 'case null:' should be exhaustive Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk17/pull/224 From jlahoda at openjdk.java.net Thu Jul 8 09:17:16 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 8 Jul 2021 09:17:16 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v9] In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: > Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`. > > How does this look? Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Adding a testcase for an enum that implements an interface. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/81/files - new: https://git.openjdk.java.net/jdk17/pull/81/files/d970402e..fe3de7d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=07-08 Stats: 25 lines in 1 file changed: 24 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81 PR: https://git.openjdk.java.net/jdk17/pull/81 From jlahoda at openjdk.java.net Thu Jul 8 09:23:52 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 8 Jul 2021 09:23:52 GMT Subject: [jdk17] RFR: 8269738: AssertionError when combining pattern matching and function closure In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 04:29:45 GMT, Guoxiong Li wrote: > This is a duplicated PR of the [jdk/pull/4678](https://github.com/openjdk/jdk/pull/4678). lgtm, thanks! ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/230 From mcimadamore at openjdk.java.net Thu Jul 8 09:24:49 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 8 Jul 2021 09:24:49 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v9] In-Reply-To: References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: On Thu, 8 Jul 2021 09:17:16 GMT, Jan Lahoda wrote: >> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`. >> >> How does this look? > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Adding a testcase for an enum that implements an interface. Looks good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/81 From jlahoda at openjdk.java.net Thu Jul 8 09:58:21 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 8 Jul 2021 09:58:21 GMT Subject: RFR: 8270064: Problem list tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java due to JDK-8270060 Message-ID: I don't think we can fix JDK-8270060 very quick, so proposing to problem list the test for now. ------------- Commit messages: - Fixing bugid in ProblemList.txt - 8270064: Problem list tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java due to JDK-8270060 Changes: https://git.openjdk.java.net/jdk/pull/4716/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4716&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270064 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4716.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4716/head:pull/4716 PR: https://git.openjdk.java.net/jdk/pull/4716 From mcimadamore at openjdk.java.net Thu Jul 8 10:12:49 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 8 Jul 2021 10:12:49 GMT Subject: RFR: 8270064: Problem list tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java due to JDK-8270060 In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 06:03:22 GMT, Jan Lahoda wrote: > I don't think we can fix JDK-8270060 very quick, so proposing to problem list the test for now. Marked as reviewed by mcimadamore (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4716 From jlahoda at openjdk.java.net Thu Jul 8 10:40:56 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 8 Jul 2021 10:40:56 GMT Subject: Integrated: 8270064: Problem list tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java due to JDK-8270060 In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 06:03:22 GMT, Jan Lahoda wrote: > I don't think we can fix JDK-8270060 very quick, so proposing to problem list the test for now. This pull request has now been integrated. Changeset: 30bba54b Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/30bba54b97fc5d941f24f9155520b47d8fe4de23 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8270064: Problem list tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java due to JDK-8270060 Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/4716 From jlahoda at openjdk.java.net Thu Jul 8 12:00:02 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 8 Jul 2021 12:00:02 GMT Subject: [jdk17] Integrated: 8268766: Desugaring of pattern matching enum switch should be improved In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: On Wed, 16 Jun 2021 15:15:25 GMT, Jan Lahoda wrote: > Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`. > > How does this look? This pull request has now been integrated. Changeset: fa08cc62 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk17/commit/fa08cc62df10e4b6e3cbc45d4e889191d67048c4 Stats: 470 lines in 7 files changed: 329 ins; 68 del; 73 mod 8268766: Desugaring of pattern matching enum switch should be improved Reviewed-by: mcimadamore, psandoz ------------- PR: https://git.openjdk.java.net/jdk17/pull/81 From maurizio.cimadamore at oracle.com Thu Jul 8 13:14:57 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 8 Jul 2021 14:14:57 +0100 Subject: Error messages technically true but that does not help if several cases have the same erasure In-Reply-To: <1080252499.2379333.1625679752072.JavaMail.zimbra@u-pem.fr> References: <1080252499.2379333.1625679752072.JavaMail.zimbra@u-pem.fr> Message-ID: On 07/07/2021 18:42, Remi Forax wrote: > The same is true for > List list = null; > switch (list) { > case List l -> System.out.println("list2"); > case List l -> System.out.println("list1"); > } > > which reports > PatternMatchingWrongDominated.java:18: error: duplicate total pattern > case List l -> System.out.println("list1"); > ^ > > > I think javac should have a specific error if two cases have the same erasure. I tend to agree, javac usually adds "detailed" messages, in parenthesis after the main issue. So this could be: ``` PatternMatchingWrongDominated.java:18: error: duplicate total pattern case List l -> System.out.println("list1"); ^ (List and List have the same erasure) ``` Maurizio From vromero at openjdk.java.net Thu Jul 8 13:56:49 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 8 Jul 2021 13:56:49 GMT Subject: [jdk17] RFR: 8269738: AssertionError when combining pattern matching and function closure In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 04:29:45 GMT, Guoxiong Li wrote: > This is a duplicated PR of the [jdk/pull/4678](https://github.com/openjdk/jdk/pull/4678). looks good! ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/230 From gli at openjdk.java.net Thu Jul 8 14:20:55 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 8 Jul 2021 14:20:55 GMT Subject: [jdk17] Integrated: 8269738: AssertionError when combining pattern matching and function closure In-Reply-To: References: Message-ID: <90ZZZUzMkCJCDauqpn8P_rEC6MwKyQmHXoyhPmQt-bU=.bdc3e69f-e518-4c9d-959d-c653ac7178d2@github.com> On Thu, 8 Jul 2021 04:29:45 GMT, Guoxiong Li wrote: > This is a duplicated PR of the [jdk/pull/4678](https://github.com/openjdk/jdk/pull/4678). This pull request has now been integrated. Changeset: 9e75f922 Author: Guoxiong Li URL: https://git.openjdk.java.net/jdk17/commit/9e75f922b17146ff78589555dfb20dd0783cffbd Stats: 20 lines in 2 files changed: 18 ins; 0 del; 2 mod 8269738: AssertionError when combining pattern matching and function closure Reviewed-by: jlahoda, vromero ------------- PR: https://git.openjdk.java.net/jdk17/pull/230 From gli at openjdk.java.net Thu Jul 8 14:20:54 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 8 Jul 2021 14:20:54 GMT Subject: [jdk17] RFR: 8269738: AssertionError when combining pattern matching and function closure In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 09:20:56 GMT, Jan Lahoda wrote: >> This is a duplicated PR of the [jdk/pull/4678](https://github.com/openjdk/jdk/pull/4678). > > lgtm, thanks! @lahodaj @vicente-romero-oracle Thanks for your reviews. ------------- PR: https://git.openjdk.java.net/jdk17/pull/230 From cushon at openjdk.java.net Thu Jul 8 14:32:51 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Thu, 8 Jul 2021 14:32:51 GMT Subject: RFR: 8261088: Repeatable annotations without @Target cannot have containers that target module declarations [v3] In-Reply-To: References: <5aDBzJlzTWVrxfvLJfya21s-8t2j299igPflTCLRRHc=.bdd1767a-5cb7-4c65-be6c-292bb17ab418@github.com> Message-ID: On Thu, 10 Jun 2021 06:39:26 GMT, Liam Miller-Cushon wrote: >> Please review this fix to consolidate handling of default `@Target`s for repeated annotations, and permit repeatable annotations without an `@Target` to have container annotations that explicitly target `MODULE`. > > Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8261088: Repeatable annotations without @Target cannot have containers that target module declarations > This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! This pull request is still active, I'm waiting for a CSR review: https://bugs.openjdk.java.net/browse/JDK-8261181?focusedCommentId=14431621&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14431621 ------------- PR: https://git.openjdk.java.net/jdk/pull/2412 From jlahoda at openjdk.java.net Thu Jul 8 15:36:17 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 8 Jul 2021 15:36:17 GMT Subject: [jdk17] RFR: 8269146: Missing unreported constraints on pattern and other case label combination [v3] In-Reply-To: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> References: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> Message-ID: > There is a number of constraints on the case label forms - patterns cannot be combined with patterns, etc. Currently, the checks are implemented by checking if there are clashing bindings. But this misses some of the cases which should lead to errors. This patch proposes to implement explicit checks on the structure of the case labels in `Attr.handleSwitch`, rather than relying on clashing bindings. Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Only run the pattern structural checks for pattern matching switches. - Adding javadoc. - Merging master into JDK-8269146 - Moving structural switch case checks from Attr to Check. - Fixing fallthrough. - Adding test summary. - Improving code. - Merging master into JDK-8269146 - 8269146: Missing unreported constraints on pattern and other case label combination ------------- Changes: https://git.openjdk.java.net/jdk17/pull/194/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=194&range=02 Stats: 319 lines in 8 files changed: 290 ins; 13 del; 16 mod Patch: https://git.openjdk.java.net/jdk17/pull/194.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/194/head:pull/194 PR: https://git.openjdk.java.net/jdk17/pull/194 From jlahoda at openjdk.java.net Thu Jul 8 15:36:18 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 8 Jul 2021 15:36:18 GMT Subject: [jdk17] RFR: 8269146: Missing unreported constraints on pattern and other case label combination [v2] In-Reply-To: References: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> Message-ID: On Thu, 1 Jul 2021 13:26:25 GMT, Jan Lahoda wrote: >> There is a number of constraints on the case label forms - patterns cannot be combined with patterns, etc. Currently, the checks are implemented by checking if there are clashing bindings. But this misses some of the cases which should lead to errors. This patch proposes to implement explicit checks on the structure of the case labels in `Attr.handleSwitch`, rather than relying on clashing bindings. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing fallthrough. I've updated the patch so that the new (/structural) tests are moved from Attr to Check. To me, looks better. What do you think? Thanks! ------------- PR: https://git.openjdk.java.net/jdk17/pull/194 From jan.lahoda at oracle.com Thu Jul 8 15:42:07 2021 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 8 Jul 2021 17:42:07 +0200 Subject: Error messages technically true but that does not help if several cases have the same erasure In-Reply-To: References: <1080252499.2379333.1625679752072.JavaMail.zimbra@u-pem.fr> Message-ID: <3e6bfb6b-29ba-43b7-2dd5-52d04622b532@oracle.com> Thanks, I've filled: https://bugs.openjdk.java.net/browse/JDK-8270102 Jan On 08. 07. 21 15:14, Maurizio Cimadamore wrote: > > On 07/07/2021 18:42, Remi Forax wrote: >> The same is true for >> ?? List list =? null; >> ?? switch (list) { >> ???? case List l -> System.out.println("list2"); >> ???? case List l -> System.out.println("list1"); >> ?? } >> >> which reports >> PatternMatchingWrongDominated.java:18: error: duplicate total pattern >> ?????? case List l -> System.out.println("list1"); >> ??????????? ^ >> >> >> I think javac should have a specific error if two cases have the same >> erasure. > > I tend to agree, javac usually adds "detailed" messages, in > parenthesis after the main issue. So this could be: > > ``` > PatternMatchingWrongDominated.java:18: error: duplicate total pattern > ????? case List l -> System.out.println("list1"); > ?????????? ^ > (List and List have the same erasure) > > ``` > > > Maurizio > > From mcimadamore at openjdk.java.net Thu Jul 8 15:48:56 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 8 Jul 2021 15:48:56 GMT Subject: [jdk17] RFR: 8269146: Missing unreported constraints on pattern and other case label combination [v3] In-Reply-To: References: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> Message-ID: On Thu, 8 Jul 2021 15:36:17 GMT, Jan Lahoda wrote: >> There is a number of constraints on the case label forms - patterns cannot be combined with patterns, etc. Currently, the checks are implemented by checking if there are clashing bindings. But this misses some of the cases which should lead to errors. This patch proposes to implement explicit checks on the structure of the case labels in `Attr.handleSwitch`, rather than relying on clashing bindings. > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Only run the pattern structural checks for pattern matching switches. > - Adding javadoc. > - Merging master into JDK-8269146 > - Moving structural switch case checks from Attr to Check. > - Fixing fallthrough. > - Adding test summary. > - Improving code. > - Merging master into JDK-8269146 > - 8269146: Missing unreported constraints on pattern and other case label combination Looks good - I agree the code looks simpler, and there's a bit more separation of concerns ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/194 From jjg at openjdk.java.net Thu Jul 8 18:48:30 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 8 Jul 2021 18:48:30 GMT Subject: RFR: JDK-8268420: new Reporter method to report a diagnostic within a DocTree node [v3] In-Reply-To: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> References: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> Message-ID: > Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string. > > This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc. > > The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes. > > There are some cosmetic cleanups that were made while exploring the current solution. > > The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream. Jonathan Gibbons 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 five additional commits since the last revision: - Update Reporter spec; add methods to Messages - Merge remote-tracking branch 'upstream/master' into 8268420.Reporter-DocTree-pos - Merge remote-tracking branch 'upstream/master' into 8268420.Reporter-DocTree-pos - Address review feedback - JDK-8268420 new Reporter method to report a diagnostic within a DocTree node ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4489/files - new: https://git.openjdk.java.net/jdk/pull/4489/files/e3d9721b..01dcf69e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4489&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4489&range=01-02 Stats: 87063 lines in 1538 files changed: 45584 ins; 34440 del; 7039 mod Patch: https://git.openjdk.java.net/jdk/pull/4489.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4489/head:pull/4489 PR: https://git.openjdk.java.net/jdk/pull/4489 From duke at openjdk.java.net Thu Jul 8 19:42:55 2021 From: duke at openjdk.java.net (duke) Date: Thu, 8 Jul 2021 19:42:55 GMT Subject: Withdrawn: JDK-8267041: javac crash when creating lambda with capture inside a switch expression In-Reply-To: References: Message-ID: On Thu, 13 May 2021 13:46:13 GMT, Jan Lahoda wrote: > Variables declared inside switch expressions used as initializers to fields have the field as their owner. We need to make sure they are captured by `LambdaToMethod` - there were a few places where the checks were missing, leading to a crash later during code generation. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4012 From prappo at openjdk.java.net Thu Jul 8 21:28:04 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 8 Jul 2021 21:28:04 GMT Subject: RFR: JDK-8268420: new Reporter method to report a diagnostic within a DocTree node [v3] In-Reply-To: References: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> Message-ID: On Thu, 8 Jul 2021 18:48:30 GMT, Jonathan Gibbons wrote: >> Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string. >> >> This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc. >> >> The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes. >> >> There are some cosmetic cleanups that were made while exploring the current solution. >> >> The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream. > > Jonathan Gibbons 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 five additional commits since the last revision: > > - Update Reporter spec; add methods to Messages > - Merge remote-tracking branch 'upstream/master' into 8268420.Reporter-DocTree-pos > - Merge remote-tracking branch 'upstream/master' into 8268420.Reporter-DocTree-pos > - Address review feedback > - JDK-8268420 > new Reporter method to report a diagnostic within a DocTree node Please address the earlier comments https://github.com/openjdk/jdk/pull/4489#discussion_r653797909 and https://github.com/openjdk/jdk/pull/4489#discussion_r653799103. src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Reporter.java line 99: > 97: * @implNote > 98: * This implementation ignores the {@code (start, pos, end)} values and simply calls > 99: * {@link #print(Diagnostic.Kind, DocTreePath,String) print(kind, path, message)}; Is there a particular reason for that trailing `;` ? Shouldn't there be `.` instead? ------------- Changes requested by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4489 From jwilhelm at openjdk.java.net Thu Jul 8 22:15:23 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 8 Jul 2021 22:15:23 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8269722: NPE in HtmlDocletWriter - 8270109: ProblemList 4 SA tests on macOS-aarch64 - 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF - 8269738: AssertionError when combining pattern matching and function closure - 8269828: corrections in some instruction patterns for KNL x86 platform - 8268766: Desugaring of pattern matching enum switch should be improved - 8270006: Switches with 'case null:' should be exhaustive - 8269746: C2: assert(!in->is_CFG()) failed: CFG Node with no controlling input? The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4734&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4734&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4734/files Stats: 675 lines in 22 files changed: 514 ins; 69 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/4734.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4734/head:pull/4734 PR: https://git.openjdk.java.net/jdk/pull/4734 From jjg at openjdk.java.net Thu Jul 8 22:44:11 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 8 Jul 2021 22:44:11 GMT Subject: RFR: JDK-8266565: Spec of ForwardingJavaFileManager/ForwardingFileObjectorwardingJavaFileObject methods should mention delegation instead of being copied Message-ID: Please review a simple doc-only clarification to the spec for the `Forwarding...` classes in `javax.tools`. The change is as in the CSR. ------------- Commit messages: - JDK-8266565: Spec of ForwardingJavaFileManager/ForwardingFileObject/ForwardingJavaFileObject methods should mention delegation instead of being copied Changes: https://git.openjdk.java.net/jdk/pull/4735/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4735&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266565 Stats: 11 lines in 3 files changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4735.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4735/head:pull/4735 PR: https://git.openjdk.java.net/jdk/pull/4735 From jjg at openjdk.java.net Thu Jul 8 22:46:32 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 8 Jul 2021 22:46:32 GMT Subject: RFR: JDK-8268420: new Reporter method to report a diagnostic within a DocTree node [v4] In-Reply-To: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> References: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> Message-ID: > Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string. > > This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc. > > The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes. > > There are some cosmetic cleanups that were made while exploring the current solution. > > The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: change @implNote to @implSpec ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4489/files - new: https://git.openjdk.java.net/jdk/pull/4489/files/01dcf69e..1ac79630 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4489&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4489&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4489.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4489/head:pull/4489 PR: https://git.openjdk.java.net/jdk/pull/4489 From jwilhelm at openjdk.java.net Thu Jul 8 23:26:58 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 8 Jul 2021 23:26:58 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: <6ALwXMfEvort2mrUB7Rb6uPlC5PrajJvaCgSgjT9fLE=.75f30de8-dbe4-4688-9515-974bfd752bc6@github.com> On Thu, 8 Jul 2021 22:06:32 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: dfd6b2be Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/dfd6b2be7d2cc312bf550a475be91072259f88af Stats: 675 lines in 22 files changed: 514 ins; 69 del; 92 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4734 From jwilhelm at openjdk.java.net Thu Jul 8 23:26:57 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 8 Jul 2021 23:26:57 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: <_0-tAFx8fVm6a77TjBchf_Wvh8Ja3pdsOxTtErgRLHM=.5b1936a7-0bf3-47ac-b852-bbfc5b89c975@github.com> > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 192 commits: - Merge - 8269827: JMH tests for AES/GCM byte[] and bytebuffers Reviewed-by: ecaspole, weijun - 8268965: TCP Connection Reset when connecting simple socket to SSL server Reviewed-by: xuelei - 8270096: Shenandoah: Optimize gc/shenandoah/TestRefprocSanity.java for interpreter mode Reviewed-by: zgu - 8269962: SA has unused Hashtable, Dictionary classes Reviewed-by: cjplummer, iklam, dholmes - 8270021: Incorrect log decorators in gc/g1/plab/TestPLABEvacuationFailure.java Reviewed-by: tschatzl, iwalulya - 8270064: Problem list tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java due to JDK-8270060 Reviewed-by: mcimadamore - 8267982: Set the node after peephole optimization to be removed Reviewed-by: kvn, thartmann - 8269886: Inaccurate error message for compressed hprof test Reviewed-by: dholmes, cjplummer - 8269803: G1: remove unnecessary NoRefDiscovery Reviewed-by: tschatzl, kbarrett - ... and 182 more: https://git.openjdk.java.net/jdk/compare/64016338...f59792e7 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4734/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4734&range=01 Stats: 48561 lines in 880 files changed: 21838 ins; 23621 del; 3102 mod Patch: https://git.openjdk.java.net/jdk/pull/4734.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4734/head:pull/4734 PR: https://git.openjdk.java.net/jdk/pull/4734 From vromero at openjdk.java.net Fri Jul 9 01:15:53 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 9 Jul 2021 01:15:53 GMT Subject: RFR: JDK-8266565: Spec of ForwardingJavaFileManager/ForwardingFileObject/ForwardingJavaFileObject methods should mention delegation instead of being copied In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 22:35:42 GMT, Jonathan Gibbons wrote: > Please review a simple doc-only clarification to the spec for the `Forwarding...` classes in `javax.tools`. > > The change is as in the CSR. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4735 From jlahoda at openjdk.java.net Fri Jul 9 08:07:03 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 9 Jul 2021 08:07:03 GMT Subject: [jdk17] Integrated: 8269146: Missing unreported constraints on pattern and other case label combination In-Reply-To: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> References: <5V-yL37-6eQ2FLbNsAG3xryIJIThXKkexx7tGQhJaHU=.61a596fe-51ec-4353-aed5-809f1a9ae0d0@github.com> Message-ID: On Thu, 1 Jul 2021 11:29:03 GMT, Jan Lahoda wrote: > There is a number of constraints on the case label forms - patterns cannot be combined with patterns, etc. Currently, the checks are implemented by checking if there are clashing bindings. But this misses some of the cases which should lead to errors. This patch proposes to implement explicit checks on the structure of the case labels in `Attr.handleSwitch`, rather than relying on clashing bindings. This pull request has now been integrated. Changeset: 885f7b11 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk17/commit/885f7b1141d1d8e6b560ebaf0c2d4878be0ea8ba Stats: 319 lines in 8 files changed: 290 ins; 13 del; 16 mod 8269146: Missing unreported constraints on pattern and other case label combination 8269301: Switch statement with a pattern, constant and default label elements crash javac Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk17/pull/194 From jlahoda at openjdk.java.net Fri Jul 9 11:07:20 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 9 Jul 2021 11:07:20 GMT Subject: [jdk17] Integrated: 8270151: IncompatibleClassChangeError on empty pattern switch statement case Message-ID: Consider code like: sealed interface I {} final class A implements I {} ... I i = null; switch (i) { case A a: } The switch is exhaustive, and javac must generate a synthetic default clause throwing an `IncompatibleClassChangeError` for the case where the permitted classes for I changes. The default clause is generated at the end of the switch statement, and consequently the execution will fall through from `case A a:` to this synthetic default, causing the `IncompatibleClassChangeError` for a valid input. (Note this was not a problem for switch expressions, as the last case can never complete normally for a switch expression.) This PR proposes to put the synthetic default at the beginning of the switch statement, rather than at the end, which should avoid fall-through issues. An alternative solution would be to generate a synthetic break into the last case, but that is a bit tricky, so placing the default at the beginning seems more reliable to me. ------------- Commit messages: - Generate synthetic breaks at the beginning of switches rather than at the end, to avoid issues if the statements in the last case complete normally. Changes: https://git.openjdk.java.net/jdk17/pull/237/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=237&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270151 Stats: 24 lines in 3 files changed: 21 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/237.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/237/head:pull/237 PR: https://git.openjdk.java.net/jdk17/pull/237 From mcimadamore at openjdk.java.net Fri Jul 9 11:07:20 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 9 Jul 2021 11:07:20 GMT Subject: [jdk17] Integrated: 8270151: IncompatibleClassChangeError on empty pattern switch statement case In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 10:00:06 GMT, Jan Lahoda wrote: > Consider code like: > > sealed interface I {} > final class A implements I {} > ... > I i = null; > switch (i) { > case A a: > } > > > The switch is exhaustive, and javac must generate a synthetic default clause throwing an `IncompatibleClassChangeError` for the case where the permitted classes for I changes. The default clause is generated at the end of the switch statement, and consequently the execution will fall through from `case A a:` to this synthetic default, causing the `IncompatibleClassChangeError` for a valid input. (Note this was not a problem for switch expressions, as the last case can never complete normally for a switch expression.) > > This PR proposes to put the synthetic default at the beginning of the switch statement, rather than at the end, which should avoid fall-through issues. An alternative solution would be to generate a synthetic break into the last case, but that is a bit tricky, so placing the default at the beginning seems more reliable to me. Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/237 From jlahoda at openjdk.java.net Fri Jul 9 11:07:21 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 9 Jul 2021 11:07:21 GMT Subject: [jdk17] Integrated: 8270151: IncompatibleClassChangeError on empty pattern switch statement case In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 10:00:06 GMT, Jan Lahoda wrote: > Consider code like: > > sealed interface I {} > final class A implements I {} > ... > I i = null; > switch (i) { > case A a: > } > > > The switch is exhaustive, and javac must generate a synthetic default clause throwing an `IncompatibleClassChangeError` for the case where the permitted classes for I changes. The default clause is generated at the end of the switch statement, and consequently the execution will fall through from `case A a:` to this synthetic default, causing the `IncompatibleClassChangeError` for a valid input. (Note this was not a problem for switch expressions, as the last case can never complete normally for a switch expression.) > > This PR proposes to put the synthetic default at the beginning of the switch statement, rather than at the end, which should avoid fall-through issues. An alternative solution would be to generate a synthetic break into the last case, but that is a bit tricky, so placing the default at the beginning seems more reliable to me. This pull request has now been integrated. Changeset: 1196b356 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk17/commit/1196b3568459511df7534848ac42f13489c61be6 Stats: 24 lines in 3 files changed: 21 ins; 0 del; 3 mod 8270151: IncompatibleClassChangeError on empty pattern switch statement case Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk17/pull/237 From jjg at openjdk.java.net Fri Jul 9 14:54:55 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 9 Jul 2021 14:54:55 GMT Subject: Integrated: JDK-8266565: Spec of ForwardingJavaFileManager/ForwardingFileObject/ForwardingJavaFileObject methods should mention delegation instead of being copied In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 22:35:42 GMT, Jonathan Gibbons wrote: > Please review a simple doc-only clarification to the spec for the `Forwarding...` classes in `javax.tools`. > > The change is as in the CSR. This pull request has now been integrated. Changeset: 5a742910 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/5a742910135a66ba96d7d7e7a7af28d82a620289 Stats: 11 lines in 3 files changed: 9 ins; 0 del; 2 mod 8266565: Spec of ForwardingJavaFileManager/ForwardingFileObject/ForwardingJavaFileObject methods should mention delegation instead of being copied Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/4735 From jjg at openjdk.java.net Fri Jul 9 15:07:30 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 9 Jul 2021 15:07:30 GMT Subject: RFR: JDK-8268420: new Reporter method to report a diagnostic within a DocTree node [v5] In-Reply-To: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> References: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> Message-ID: > Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string. > > This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc. > > The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes. > > There are some cosmetic cleanups that were made while exploring the current solution. > > The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: address review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4489/files - new: https://git.openjdk.java.net/jdk/pull/4489/files/1ac79630..d124eb2b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4489&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4489&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4489.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4489/head:pull/4489 PR: https://git.openjdk.java.net/jdk/pull/4489 From prappo at openjdk.java.net Fri Jul 9 15:34:52 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 9 Jul 2021 15:34:52 GMT Subject: RFR: JDK-8268420: new Reporter method to report a diagnostic within a DocTree node [v5] In-Reply-To: References: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> Message-ID: On Fri, 9 Jul 2021 15:07:30 GMT, Jonathan Gibbons wrote: >> Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string. >> >> This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc. >> >> The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes. >> >> There are some cosmetic cleanups that were made while exploring the current solution. >> >> The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > address review feedback Looks good. I only note that Reporter now imports four types from the com.sun.source.doctree package for documentation purposes; it's not bad, but it's worth noting. Will anyone from the compiler team review this change too? test/langtools/jdk/javadoc/doclet/testDocTreeDiags/MyTaglet.java line 50: > 48: > 49: /** > 50: * A taglet to be called in the context of the sdtandard doclet. A typo: sdtandard ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4489 From jjg at openjdk.java.net Fri Jul 9 16:11:20 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 9 Jul 2021 16:11:20 GMT Subject: RFR: JDK-8268420: new Reporter method to report a diagnostic within a DocTree node [v6] In-Reply-To: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> References: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> Message-ID: > Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string. > > This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc. > > The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes. > > There are some cosmetic cleanups that were made while exploring the current solution. > > The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: fix typos ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4489/files - new: https://git.openjdk.java.net/jdk/pull/4489/files/d124eb2b..435ae6a2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4489&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4489&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4489.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4489/head:pull/4489 PR: https://git.openjdk.java.net/jdk/pull/4489 From jjg at openjdk.java.net Fri Jul 9 16:19:01 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 9 Jul 2021 16:19:01 GMT Subject: Integrated: JDK-8268420: new Reporter method to report a diagnostic within a DocTree node In-Reply-To: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> References: <_rKwE0lZFYFSnBNwLQRcaRiJnoAr6ZVXwyJSaXPnNQs=.d47a5ae3-c6fb-4a5b-aa32-9359d91eb912@github.com> Message-ID: On Mon, 14 Jun 2021 21:45:11 GMT, Jonathan Gibbons wrote: > Please review an update to add a new method in Reporter to report a diagnostic within a DocTree node for those DocTree nodes that wrap a string. > > This is the last of the current round of updates to improve the diagnostics that can be generated by javadoc. > > The general fix, in JavadocLog and Reporter, is pretty simple, given all the improvements in recent related changes. > > There are some cosmetic cleanups that were made while exploring the current solution. > > The test is "reasonably thorough" and uses a custom taglet to generate diagnostics for selected nodes in doc comment trees. The test then "algorithmically validates" (i.e. no golden files or text blocks) the diagnostics that are either passed to a DiagnosticListener or written to the console stream. This pull request has now been integrated. Changeset: 3588634d Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/3588634d5403a6472fc88eb2ad8576f55cad2f89 Stats: 586 lines in 9 files changed: 569 ins; 5 del; 12 mod 8268420: new Reporter method to report a diagnostic within a DocTree node Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/4489 From jwilhelm at openjdk.java.net Sat Jul 10 00:26:17 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Sat, 10 Jul 2021 00:26:17 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8268826: Cleanup Override in Context-Specific Deserialization Filters - 8261147: C2: Node is wrongly marked as reduction resulting in a wrong execution due to wrong vector instructions - 8270151: IncompatibleClassChangeError on empty pattern switch statement case - 8269146: Missing unreported constraints on pattern and other case label combination - 8269952: compiler/vectorapi/VectorCastShape*Test.java tests failed on avx2 machines - 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4748&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4748&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4748/files Stats: 691 lines in 29 files changed: 544 ins; 66 del; 81 mod Patch: https://git.openjdk.java.net/jdk/pull/4748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4748/head:pull/4748 PR: https://git.openjdk.java.net/jdk/pull/4748 From jwilhelm at openjdk.java.net Sat Jul 10 01:26:52 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Sat, 10 Jul 2021 01:26:52 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: On Sat, 10 Jul 2021 00:17:07 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: ec975c6a Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/ec975c6a055688c014e709917dcfc340037e684f Stats: 691 lines in 29 files changed: 544 ins; 66 del; 81 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4748 From gli at openjdk.java.net Sun Jul 11 12:03:58 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Sun, 11 Jul 2021 12:03:58 GMT Subject: RFR: 8268894: ArrayIndexOutOfBoundsException in jdk compiler: at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writePosition(ClassWriter.java:671) Message-ID: Hi all, The method `TypeAnnotationPosition.updatePosOffset` sets the `lvarOffset` unnecessarily. After invoking `TypeAnnotationPosition.updatePosOffset`, the lengths of (`lvarOffset`, `lvarLength`, `lvarIndex`) are respectively (1, 0, 0). Then `Code.fillLocalVarPosition` fills the `lvarOffset`, `lvarLength`, `lvarIndex` which make their lengths become (N, N-1, N-1). At last, the method `ClassWrite.writePosition` uses these three arrays whose lengths are not the same so that the `ArrayIndexOutOfBoundsException` occurs. The `lvarOffset` should be always changed along with `lvarLength` and `lvarIndex` so that their lengths can be the same. This patch removes the unnecessary `lvarOffset = new int[]{to};` of the method `TypeAnnotationPosition.updatePosOffset` and add a corresponding test. --- Steps to reproduce the issue: 1. Construct a annotation processor which set the `pos` of the method sub-tree nodes to the same position. Please see the file `TypeAnnotationPositionProcessor.java` for more details. 2. Compile the code which has the corresponding method with the annotated local variable by using the annotation processor generated at the step 1. Please see the file `TypeAnnotationPositionTest.java` for more details. 3. Then the crash occurs. Actually, this bug may never occur if the users use the compiler friendly. Because the method `TypeAnnotationPosition.updatePosOffset`, which we mentioned at the beginning, may never be invoked at the situation that the different trees has different and right position. The lib `lombok` constructs some new tree nodes by using the internal method of the compiler. But it doesn't set the `pos` correctly and uses the same fake position. The unfriendly code of the `lombok` is in the method [JavacHandlerUtil.setGeneratedBy](https://github.com/projectlombok/lombok/blob/master/src/core/lombok/javac/handlers/JavacHandlerUtil.java#L167). At much time, the fake same position works well, but this time, it crashes the compiler. --- A brief history: According to the git's records, I found the code `ta.position.lvarOffset = new int[] { code.cp };` was firstly added at [8006775: JSR 308: Compiler changes in JDK8](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l52.35) . Then, [8013852: update reference impl for type-annotations](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ddb4a2bfcd82#l8.52) moved the code to `TypeAnnotationPosition.updatePosOffset`. The bug didn't occur at that time, because the old [Code.fillLocalVarPosition](http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/71f35e4b93a5#l51.21) always created a new array instead of using the old array. But later, [8231826: Implement javac changes for pattern matching for instanceof](https://hg.openjdk.java.net/jdk/jdk/rev/7799a51dbe30#l24.27) revised the method `Code.fillLocalVarPosition` to reuse the old array so that the bug occurs. Concluded, this is an issue introduced at JDK8 when implementing the type annotation. But it was hidden by other code at the past. --- Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 8268894: ArrayIndexOutOfBoundsException in jdk compiler: at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writePosition(ClassWriter.java:671) Changes: https://git.openjdk.java.net/jdk/pull/4749/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4749&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268894 Stats: 134 lines in 3 files changed: 133 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4749.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4749/head:pull/4749 PR: https://git.openjdk.java.net/jdk/pull/4749 From jlaskey at openjdk.java.net Mon Jul 12 12:55:53 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 12 Jul 2021 12:55:53 GMT Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v4] In-Reply-To: References: Message-ID: > \u005C Unicode escape sequence not being treated as a backslash for general escape sequences. Jim Laskey 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 four additional commits since the last revision: - Merge branch 'master' into 8269150 - Updated the test to include all combinations - Merge branch 'master' into 8269150 - Correct unicode escape handling in UnicodeReader, added test ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/126/files - new: https://git.openjdk.java.net/jdk17/pull/126/files/3e2886d6..8c5f1acd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=126&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=126&range=02-03 Stats: 10172 lines in 284 files changed: 7600 ins; 1274 del; 1298 mod Patch: https://git.openjdk.java.net/jdk17/pull/126.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/126/head:pull/126 PR: https://git.openjdk.java.net/jdk17/pull/126 From duke at openjdk.java.net Wed Jul 14 07:57:18 2021 From: duke at openjdk.java.net (duke) Date: Wed, 14 Jul 2021 07:57:18 GMT Subject: Withdrawn: 8267355: Adjust the parameters of the method UnicodeReader#digit In-Reply-To: References: Message-ID: On Wed, 19 May 2021 06:39:23 GMT, Guoxiong Li wrote: > Hi all, > > This patch removes the parameter `int pos` of the method `UnicodeReader#digit`. Several places which use the method `UnicodeReader#digit` are adjusted, too. > > Thank you for taking the time to review. > > --- > > A related issue for comments. > > After merging this patch, the methods `JavaTokenizer#scanLitChar` and `JavaTokenizer#scanDigits` also have the unused parameters `int pos`. It seems that they could be removed, too. > But I consider that the methods `scan***` of the class `JavaTokenizer` have a context which may look ahead or back. So their parameters `int pos` may be used in the future. Maybe it is good to remain them. > > What's your opionion? Any idea is appreciated. > > --- > > Best Regards, > -- Guoxiong This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4106 From jjg at openjdk.java.net Wed Jul 14 17:56:23 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 14 Jul 2021 17:56:23 GMT Subject: RFR: JDK-8265888: StandardJavaFileManager::setLocationForModule specification misses 'Implementation Requirements:' Message-ID: Please review a simple `no-reg` doc fix to add an `@implSpec` to StandardJavaFileManager::setLocationForModule. The change is as for the CSR. There is no functional change. ------------- Commit messages: - JDK-8265888: StandardJavaFileManager::setLocationForModule specification misses 'Implementation Requirements:' Changes: https://git.openjdk.java.net/jdk/pull/4785/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4785&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265888 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4785.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4785/head:pull/4785 PR: https://git.openjdk.java.net/jdk/pull/4785 From darcy at openjdk.java.net Wed Jul 14 18:13:15 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 14 Jul 2021 18:13:15 GMT Subject: RFR: 8269656: The test test/langtools/tools/javac/versions/Versions.java has duplicate test cycles In-Reply-To: <-ZjbbIHEMR26D1eHVaVwhE87ZvfvbI0OqVXEMy4jSCs=.86be1787-f3c3-4a7f-bea3-967535511f9a@github.com> References: <-ZjbbIHEMR26D1eHVaVwhE87ZvfvbI0OqVXEMy4jSCs=.86be1787-f3c3-4a7f-bea3-967535511f9a@github.com> Message-ID: On Wed, 30 Jun 2021 12:04:07 GMT, Thejasvi Voniadka wrote: > The test "test test/langtools/tools/javac/versions/Versions.java" duplicates some operations, while missing some others. > > From the execution log: > > ... > test: check_source_target 52.0 8 8 > ... > test: check_source_target 52.0 8 8 > ... > test: check_source_target 53.0 9 9 > ... > test: check_source_target 53.0 9 9 > ... > > We can notice the duplicates. Also some combinations are missed out. For example, "check -source 7 -target 8" is an expected combination in the output, but it is missed. > > I have updated the index boundaries of the inner for-loop to address this discrepancy. > > In addition, the test code contains an unreachable block of code, that causes the combination "most recent target" without a "-source" specifier to be missed out. I have updated the corresponding "if" condition too. > > I have verified that the test passes on all platforms. Marked as reviewed by darcy (Reviewer). test/langtools/tools/javac/versions/Versions.java line 141: > 139: boolean dotOne = st.dotOne(); > 140: check_source_target(dotOne, List.of(classFileVer, target, target)); > 141: for (int j = i - 1; j >= 0; j--) { I verified this change removes redundant calls. test/langtools/tools/javac/versions/Versions.java line 160: > 158: } > 159: > 160: if (i == sourceTargets.length - 1) { And verified this adds the desired testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/4639 From darcy at openjdk.java.net Wed Jul 14 22:26:15 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 14 Jul 2021 22:26:15 GMT Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v4] In-Reply-To: References: Message-ID: On Mon, 12 Jul 2021 12:55:53 GMT, Jim Laskey wrote: >> \u005C Unicode escape sequence not being treated as a backslash for general escape sequences. > > Jim Laskey 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 four additional commits since the last revision: > > - Merge branch 'master' into 8269150 > - Updated the test to include all combinations > - Merge branch 'master' into 8269150 > - Correct unicode escape handling in UnicodeReader, added test test/langtools/tools/javac/T8269150/T8269150.java line 31: > 29: */ > 30: > 31: public class T8269150 { Please, please, please give the test a meaningful name other than a bug id. (It is true javac tested used to follow that naming convention, but it has largely been abandoned.) test/langtools/tools/javac/T8269150/T8269150.java line 33: > 31: public class T8269150 { > 32: public static void main(String... args) { > 33: String source = """ The test here would be clearer if written as a 2-D array of strings where the alternative forms of a particular sequence of characters were side-by-side on the same line. ------------- PR: https://git.openjdk.java.net/jdk17/pull/126 From vromero at openjdk.java.net Thu Jul 15 03:20:48 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 15 Jul 2021 03:20:48 GMT Subject: RFR: 8261006: 'super' qualified method references cannot occur in a static context [v7] In-Reply-To: References: Message-ID: <7WzcbTakN8P-wt64Fma6Ag-X8Zz782Nv238WHcF6hG4=.96187a6a-6958-463d-aca9-b55573dfda99@github.com> > Please review this PR, currently javac is accepting code like: > > > import java.util.function.Supplier; > > public class MethodReferenceInConstructorInvocation { > interface Bar { > default String getString() { return ""; } > } > > static class Foo implements Bar { > public Foo() { this(Bar.super::getString); } > public Foo(Supplier sString) {} > } > } > > > but the spec states in `15.13 Method Reference Expressions`: > > If a method reference expression has the form super :: [TypeArguments] Identifier > or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if > the expression occurs in a static context (?8.1.3). > > and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context. > > TIA Vicente Romero 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 JDK-8261006 - Merge branch 'master' into JDK-8261006 - addressing review comments - updating comment - addressing review comments - Merge branch 'master' into JDK-8261006 - 8261006: fail to parse broken interface::method in lambda ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4376/files - new: https://git.openjdk.java.net/jdk/pull/4376/files/cdb5c3fa..e5cc4526 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4376&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4376&range=05-06 Stats: 9879 lines in 409 files changed: 5722 ins; 2559 del; 1598 mod Patch: https://git.openjdk.java.net/jdk/pull/4376.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4376/head:pull/4376 PR: https://git.openjdk.java.net/jdk/pull/4376 From tvoniadka at openjdk.java.net Thu Jul 15 04:56:16 2021 From: tvoniadka at openjdk.java.net (Thejasvi Voniadka) Date: Thu, 15 Jul 2021 04:56:16 GMT Subject: Integrated: 8269656: The test test/langtools/tools/javac/versions/Versions.java has duplicate test cycles In-Reply-To: <-ZjbbIHEMR26D1eHVaVwhE87ZvfvbI0OqVXEMy4jSCs=.86be1787-f3c3-4a7f-bea3-967535511f9a@github.com> References: <-ZjbbIHEMR26D1eHVaVwhE87ZvfvbI0OqVXEMy4jSCs=.86be1787-f3c3-4a7f-bea3-967535511f9a@github.com> Message-ID: On Wed, 30 Jun 2021 12:04:07 GMT, Thejasvi Voniadka wrote: > The test "test test/langtools/tools/javac/versions/Versions.java" duplicates some operations, while missing some others. > > From the execution log: > > ... > test: check_source_target 52.0 8 8 > ... > test: check_source_target 52.0 8 8 > ... > test: check_source_target 53.0 9 9 > ... > test: check_source_target 53.0 9 9 > ... > > We can notice the duplicates. Also some combinations are missed out. For example, "check -source 7 -target 8" is an expected combination in the output, but it is missed. > > I have updated the index boundaries of the inner for-loop to address this discrepancy. > > In addition, the test code contains an unreachable block of code, that causes the combination "most recent target" without a "-source" specifier to be missed out. I have updated the corresponding "if" condition too. > > I have verified that the test passes on all platforms. This pull request has now been integrated. Changeset: 04b73bc4 Author: Thejasvi Voniadka Committer: Abdul Kolarkunnu URL: https://git.openjdk.java.net/jdk/commit/04b73bc4e022740122463ef70791ef276ac9b34d Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8269656: The test test/langtools/tools/javac/versions/Versions.java has duplicate test cycles Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/4639 From jlahoda at openjdk.java.net Thu Jul 15 06:41:12 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 15 Jul 2021 06:41:12 GMT Subject: RFR: JDK-8265888: StandardJavaFileManager::setLocationForModule specification misses 'Implementation Requirements:' In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 17:48:20 GMT, Jonathan Gibbons wrote: > Please review a simple `no-reg` doc fix to add an `@implSpec` to StandardJavaFileManager::setLocationForModule. > > The change is as for the CSR. There is no functional change. Looks good. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4785 From ilyas.selimov at jetbrains.com Thu Jul 15 10:07:05 2021 From: ilyas.selimov at jetbrains.com (Ilyas Selimov) Date: Thu, 15 Jul 2021 17:07:05 +0700 Subject: Switch statement containing both null and guarded pattern freezes during execution Message-ID: Hello! I tried to execute the following code using OpenJDK 17 (build 17-ea+30-2618) and got the freeze: public static void main(String[] args) { test(null); } static void test(Integer i) { switch (i) { case null: case Integer ii && ii != null: System.out.println("int"); break; default: System.out.println("def"); } } Looking at the test method's bytecode, it seems the issue is related to the "goto" instruction on the 44's position: static void test(java.lang.Integer); Code: 0: aload_0 1: astore_1 2: iconst_0 3: istore_2 4: aload_1 5: iload_2 6: invokedynamic #13, 0 // InvokeDynamic #0:typeSwitch:(Ljava/lang/Object;I)I 11: lookupswitch { // 2 -1: 36 0: 36 default: 58 } 36: aload_1 37: astore_3 38: aload_3 39: ifnonnull 47 42: iconst_1 43: istore_2 44: goto 4 47: getstatic #17 // Field java/lang/System.out:Ljava/io/PrintStream; 50: ldc #23 // String int 52: invokevirtual #25 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 55: goto 66 58: getstatic #17 // Field java/lang/System.out:Ljava/io/PrintStream; 61: ldc #31 // String def 63: invokevirtual #25 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 66: return The third_var = null, as third_var = first_var = null. So the result of "ifnonnull" instruction seems false and we meet "goto" instruction, jump before the "lookupswitch" position again. Seems the issue is related to https://bugs.openjdk.java.net/browse/JDK-8269141. Could somebody take a look? Thanks, Ilyas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Jul 15 10:24:57 2021 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 15 Jul 2021 12:24:57 +0200 Subject: Switch statement containing both null and guarded pattern freezes during execution In-Reply-To: References: Message-ID: Hi Ilyas, Please see: https://bugs.openjdk.java.net/browse/JDK-8269146 This should report a compile-time error in more recent builds: $ javac --enable-preview -source 17 T.java T.java:44: error: illegal fall-through to a pattern ??????????? case Integer ii && ii != null: ???????????????? ^ Jan On 15. 07. 21 12:07, Ilyas Selimov wrote: > Hello! > > I tried to execute the following code using OpenJDK 17 (build > 17-ea+30-2618) and got the freeze: > > ? ? public static void main(String[] args) { > ? ? ? ? test(null); > ? ? } > > ? ? static void test(Integer i) { > ? ? ? ? switch (i) { > ? ? ? ? ? ? case null: > ? ? ? ? ? ? case Integer ii && ii != null: > ? ? ? ? ? ? ? ? System.out.println("int"); > ? ? ? ? ? ? ? ? break; > ? ? ? ? ? ? default: > ? ? ? ? ? ? ? ? System.out.println("def"); > ? ? ? ? } > ? ? } > > Looking at the test method's bytecode, it seems the issue is related > to the "goto" instruction on the 44's position: > > ? static void test(java.lang.Integer); > ? ? Code: > ? ? ? ?0: aload_0 > ? ? ? ?1: astore_1 > ? ? ? ?2: iconst_0 > ? ? ? ?3: istore_2 > ? ? ? ?4: aload_1 > ? ? ? ?5: iload_2 > ? ? ? ?6: invokedynamic #13, ?0 ? ? ? ? ? ? // InvokeDynamic > #0:typeSwitch:(Ljava/lang/Object;I)I > ? ? ? 11: lookupswitch ?{ // 2 > ? ? ? ? ? ? ? ? ? ? -1: 36 > ? ? ? ? ? ? ? ? ? ? ?0: 36 > ? ? ? ? ? ? ? ?default: 58 > ? ? ? ? ? } > ? ? ? 36: aload_1 > ? ? ? 37: astore_3 > ? ? ? 38: aload_3 > ? ? ? 39: ifnonnull ? ? 47 > ? ? ? 42: iconst_1 > ? ? ? 43: istore_2 > ? ? ? 44: goto ? ? ? ? ?4 > ? ? ? 47: getstatic ? ? #17 ? ? ? ? ? ? ? ? // Field > java/lang/System.out:Ljava/io/PrintStream; > ? ? ? 50: ldc ? ? ? ? ? #23 ? ? ? ? ? ? ? ? // String int > ? ? ? 52: invokevirtual #25 ? ? ? ? ? ? ? ? // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > ? ? ? 55: goto ? ? ? ? ?66 > ? ? ? 58: getstatic ? ? #17 ? ? ? ? ? ? ? ? // Field > java/lang/System.out:Ljava/io/PrintStream; > ? ? ? 61: ldc ? ? ? ? ? #31 ? ? ? ? ? ? ? ? // String def > ? ? ? 63: invokevirtual #25 ? ? ? ? ? ? ? ? // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > ? ? ? 66: return > > The third_var = null, as third_var = first_var = null. > So the result of "ifnonnull" instruction seems false and we meet > "goto" instruction, jump before the "lookupswitch" position again. > > Seems the issue is related to > https://bugs.openjdk.java.net/browse/JDK-8269141 > . > Could somebody take a look? > > Thanks, > Ilyas From prappo at openjdk.java.net Thu Jul 15 14:24:06 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 15 Jul 2021 14:24:06 GMT Subject: RFR: 8266666: Implementation for snippets Message-ID: This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. ------------- Commit messages: - Update copyright years - Do not use snippets - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/4795/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266666 Stats: 4603 lines in 44 files changed: 4575 ins; 4 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From vromero at openjdk.java.net Thu Jul 15 15:36:51 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 15 Jul 2021 15:36:51 GMT Subject: Integrated: 8261006: 'super' qualified method references cannot occur in a static context In-Reply-To: References: Message-ID: On Sun, 6 Jun 2021 02:17:17 GMT, Vicente Romero wrote: > Please review this PR, currently javac is accepting code like: > > > import java.util.function.Supplier; > > public class MethodReferenceInConstructorInvocation { > interface Bar { > default String getString() { return ""; } > } > > static class Foo implements Bar { > public Foo() { this(Bar.super::getString); } > public Foo(Supplier sString) {} > } > } > > > but the spec states in `15.13 Method Reference Expressions`: > > If a method reference expression has the form super :: [TypeArguments] Identifier > or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if > the expression occurs in a static context (?8.1.3). > > and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context. > > TIA This pull request has now been integrated. Changeset: c962e6ec Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/c962e6ec0bdaae9ff26f851c0b03551adad18ad8 Stats: 36 lines in 3 files changed: 33 ins; 0 del; 3 mod 8261006: 'super' qualified method references cannot occur in a static context Reviewed-by: sadayapalam ------------- PR: https://git.openjdk.java.net/jdk/pull/4376 From jjg at openjdk.java.net Thu Jul 15 16:10:15 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 15 Jul 2021 16:10:15 GMT Subject: Integrated: JDK-8265888: StandardJavaFileManager::setLocationForModule specification misses 'Implementation Requirements:' In-Reply-To: References: Message-ID: <3t6S1P8YXJZnNG5eqzlyV0OJ_hXG4r8kr4goomC8e00=.41b18a6a-4949-484c-8622-d88e011c74bb@github.com> On Wed, 14 Jul 2021 17:48:20 GMT, Jonathan Gibbons wrote: > Please review a simple `no-reg` doc fix to add an `@implSpec` to StandardJavaFileManager::setLocationForModule. > > The change is as for the CSR. There is no functional change. This pull request has now been integrated. Changeset: 1f995e52 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/1f995e52b2af0bdc3044c27a15ee8da446f02de8 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8265888: StandardJavaFileManager::setLocationForModule specification misses 'Implementation Requirements:' Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/4785 From james.laskey at oracle.com Thu Jul 15 17:43:50 2021 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 15 Jul 2021 17:43:50 +0000 Subject: JDK-8254073, unicode escape preprocessing, and \u005C In-Reply-To: References: <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com> <86520066-93a7-d24e-c86e-e9dda6b9bc9b@oracle.com> <2feaea08-2217-a094-93ef-fc519cab793e@oracle.com> Message-ID: <74E0A370-673E-445A-B9B2-E5BF5B9AD3D6@oracle.com> The fall out from discussion here and via the CSR (https://bugs.openjdk.java.net/browse/JDK-8269290) is that we have two choices (and noting today is RD2) 1) Proceed with proposed bug fix and strengthen the existing Interpretation in the JLS. 2) Withdraw the CSR, fix the bug to replicate the behaviour seen prior to JDK 16 and rework the JLS to reflect that behaviour. At this point, Alex and I feel the correct choice is 2). This choice has the least risk and is likely the least disruptive. If we see no objections here, we will move forward early next week. ? Jim On Jul 6, 2021, at 8:26 PM, Alex Buckley > wrote: (I slightly reordered the table in JDK-8269290 in support of the following exposition.) Since time immemorial, X = "\u005C\\u005D" has printed `\]` on the grounds that the six opening characters \ u 0 0 5 C form a backslash for the purpose of counting how many backslash characters contiguously precede the backslash in the final six characters \ u 0 0 5 D. (Two, making the backslash in \ u 0 0 5 D eligible to begin a Unicode escape.) Given Y = "\u005C\u005C\u005D", it's consistent for the six opening characters \ u 0 0 5 C to again form a backslash for the purpose of counting how many backslash characters contiguously precede the backslash in the middle six characters \ u 0 0 5 C. Thus, "\u005C\u005C..." is treated the same as "\\u005C...". I acknowledge this is an incompatible change, but consider the alternative. If the six opening characters *didn't* contribute a backslash to the count for \ u 0 0 5 C in the Y case, then the same six opening characters wouldn't contribute a backslash to the count for \ u 0 0 5 D in the X case. (In this alternative universe, people take the rule "The character produced by a Unicode escape does not participate in further Unicode escapes." literally.) Thus, in the X case, there would only be one backslash, denoted by the ASCII character, preceding the final six characters \ u 0 0 5 D ==> the \ in \ u 0 0 5 D would not be eligible ==> X would lex as \ \ \ u 0 0 5 D and print as `\\u005D` which is plain wrong. (Maybe there is some application of the "longest possible translation" rule from 3.2 that lets the same six opening characters become a backslash-that-counts in X but not become a backslash-that-counts in Y. However, I do not know how to describe that application.) Here's another test case for the CSR. JDK 15 does this: jshell> System.out.println("\\u005D"); \u005D jshell> System.out.println("\u005C\u005D"); | Error: | illegal escape character | System.out.println("\u005C\u005D"); | ^ With my consistency-first approach, the Z = "\u005C\u005D" case is legal, which seems far more reasonable than illegal. The six opening characters \ u 0 0 5 C form a backslash for the purpose of counting how many backslash characters contiguously precede the backslash in the final six characters \ u 0 0 5 D. (One, meaning the backslash in \ u 0 0 5 D is not eligible to begin a Unicode escape.) The result would be \ \ u 0 0 5 D which would print as `\u005D`. Net net, I favor the correct fix -- and lots more test cases in the JCK. Alex On 7/2/2021 5:47 AM, Jim Laskey wrote: Just so it doesn't look like I went rogue with the bug fix (https://bugs.openjdk.java.net/browse/JDK-8269290 ), I would like a consensus ruling on which is the bug fix I should use; correct fix: interpretAsPerJLS(); faithful fix: if (sourceLevel <= 15) interpretOldWay(); else interpretAsPerJLS(); status quo fix: interpretOldWay(); I'm assuming correct fix, but others may have different assumptions. Cheers, -- Jim On Jun 25, 2021, at 4:04 PM, Alex Buckley > wrote: I filed https://bugs.openjdk.java.net/browse/JDK-8269406 with some additional discussion about what the result of the first lexical translation step is really meant to be. Please take a look if you are familiar with the three-step translation described in JLS 3.2, and care about how the input stream is processed. Alex On 6/22/2021 10:38 AM, Alex Buckley wrote: I am minded to extend the final note in JLS 3.3 to help people understand the multi-level escape story in play when they experiment with Unicode escapes. Perhaps it will also improve some javac error messages or test cases. Let me know what you think of this: ----- For example, the input stream \u005cu005a results in the six characters \ u 0 0 5 a, because 005c is the Unicode value for \. It does not result in the character Z, which is Unicode character 005a, because the \ that resulted from the \u005c is not interpreted as the start of a further Unicode escape. Note that \u005cu005a cannot be written in a string literal to denote the six characters \ u 0 0 5 a. This is because the first two characters resulting from translation, \ and u, are interpreted in a string literal as an illegal escape sequence (3.10.7). Fortunately, the rule about contiguous \ characters helps programmers to craft input streams that denote Unicode escapes in a string literal. Denoting the six characters \ u 0 0 5 a in a string literal simply requires another \ to be written adjacent to the existing \, such as in "Z is \\u005a". This works because the second \ in the input stream \\u005a is not eligible, so the first \ and second \ are preserved as raw input characters; they are subsequently interpreted in a string literal as the escape sequence for a backslash, resulting in the desired six characters \ u 0 0 5 a. Without the rule, the input stream \\u005a would be translated as the raw input character \ followed by the Unicode escape \u005a (Z), but \Z is an illegal escape sequence in a string literal. The rule also allows programmers to craft input streams that denote escape sequences in a string literal. For example, the input stream \\\u006e results in the three characters \ \ n because the third \ is eligible and thus \u006e is translated to n, while the first \ and second \ are preserved as raw input characters. The three characters \ \ n are subsequently interpreted in a string literal as \ n which denotes the escape sequence for a linefeed. (The input stream \\\u006e may also be written as \u005c\u005c\u006e.) ----- Alex On 6/21/2021 4:41 PM, Alex Buckley wrote: There's no question that the first six raw input characters \ u 0 0 5 c are identified as a Unicode escape \u005c and translated to a backslash. The question is whether that backslash is then treated as: 1. a raw input character \ that is followed by seven more raw input characters \ \ u 0 0 5 d For these *eight* raw input characters, there are three raw input character \'s in a row. Due to contiguous-\ counting, the third raw input character \ is eligible to begin a Unicode escape; the first and second pass through and you get \ \ ] which further translates within a string literal as \] or 2. something which is independent of the subsequent seven raw input characters \ \ u 0 0 5 d For those *seven* subsequent raw input characters, there are two raw input character \'s in a row. Due to contiguous-\ counting, the second raw input character \ is not eligible to begin a Unicode escape, so all seven raw input characters pass through. You get (including the first "independent" backslash) \ \ \ u 0 0 5 d The contiguous-\ counting is due to the fact that \\ is the escape sequence for backslash in a string literal, so we don't want too many raw \ input character to "disappear" into Unicode escapes. The JDK 15 behavior was #1. That looks correct to me. \ u 0 0 5 c becomes a raw input character \ that cannot serve as the opening backslash for an *immediate* Unicode escape (the classic JLS 3.3 scenario of \u005cu005a) but that can serve as a raw input character for the purpose of skipping over \\ pairs (the purpose of contiguous-\ counting) in order for a *later* Unicode escape to be recognized (\u005d). Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them? Where JLS 3.3 says "translating the ASCII characters \u followed by four hexadecimal digits to the UTF-16 code unit (?3.1) for the indicated hexadecimal value", it really means "translating the ASCII characters \u followed by four hexadecimal digits to *a raw input character which denotes* the UTF-16 code unit (?3.1) for the indicated hexadecimal value". Thus, the later clause "for each raw input character that is a backslash \, input processing must consider how many other [raw input] \ characters contiguously precede it" can be seen more easily to include characters that result from Unicode escape processing. Alex On 6/21/2021 2:56 PM, Jim Laskey wrote: "\u005C? should have been treated as a backslash. Will check into it. Cheers, ? Jim ?? On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon > wrote: ? class T { public static void main(String[] args) { System.err.println("\u005C\\u005D"); } } Before JDK-8254073, this prints `\]`. After JDK-8254073, unicode escape processing results in `\\\u005D`, which results in an 'invalid escape' error for `\u`. Was that deliberate? JLS 3.3 says for each raw input character that is a backslash \, input processing must consider how many other \ characters contiguously precede it, separating it from a non-\ character or the start of the input stream. If this number is even, then the \ is eligible to begin a Unicode escape; if the number is odd, then the \ is not eligible to begin a Unicode escape. The difference is in whether `\u005C` (the unicode escape for `\`) counts as one of the `\` preceding a valid unicode escape. Does "how many other \ characters contiguously precede it" refer to preceding raw input characters, or does it refer to preceding characters after unicode escape processing is performed on them? JLS 3.3 also mentions that a "character produced by a Unicode escape does not participate in further Unicode escapes", but I'm not sure if that applies here, since in the pre-JDK-8254073 interpretation the unicode-escaped backslash isn't really 'participating' in the second unicode escape. Thanks, Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Thu Jul 15 18:16:59 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 15 Jul 2021 11:16:59 -0700 Subject: JDK-8254073, unicode escape preprocessing, and \u005C In-Reply-To: <74E0A370-673E-445A-B9B2-E5BF5B9AD3D6@oracle.com> References: <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com> <86520066-93a7-d24e-c86e-e9dda6b9bc9b@oracle.com> <2feaea08-2217-a094-93ef-fc519cab793e@oracle.com> <74E0A370-673E-445A-B9B2-E5BF5B9AD3D6@oracle.com> Message-ID: <912ec012-6ad0-1ac6-7019-3c2680de2a8f@oracle.com> On 7/15/2021 10:43 AM, Jim Laskey wrote: > The fall out from discussion here and via the CSR > (https://bugs.openjdk.java.net/browse/JDK-8269290 > ) is that we have two > choices (and noting today is RD2) > > 1) Proceed with proposed bug fix and strengthen?the existing > Interpretation in the JLS. > > 2) Withdraw the CSR, fix the bug to replicate the behaviour seen prior > to JDK 16 and rework the JLS to reflect that behaviour. > > At this point, Alex and I feel the correct choice is 2). This choice has > the least risk and is likely the least disruptive. For the record, in support of #2, here's the rework to JLS 3.3 which makes it fully describe the behavior of javac 15. This behavior is not completely intuitive, either to specify or implement, but it is the historical precedent. ----- ~In addition to the processing implied by the grammar,~ +The UnicodeInputCharacter production is ambiguous because an ASCII \ character in the input stream could be reduced to either a RawInputCharacter or to the \ of a UnicodeEscape (to be followed by an ASCII u). To avoid ambiguity,+ [All new text follows] for each ASCII \ character in the input stream, input processing must consider the most recent raw input characters that resulted from this translation step: - If the most recent raw input character was itself translated from a Unicode escape in the input stream, then the ASCII \ character is eligible to begin a Unicode escape. (For example, if the most recent raw input character in the result was a backslash that arose from a Unicode escape \u005c in the input stream, then an ASCII \ character in the input stream is eligible to begin another Unicode escape.) - Otherwise, consider how many backslashes appeared contiguously as raw input characters in the result, back to a non-backslash character or the start of the result. (It is immaterial whether any such backslash arose from an ASCII \ character in the input stream or from a Unicode escape \u005c in the input stream.) If this number is even, then the ASCII \ character is eligible to begin a Unicode escape; if the number is odd, then the ASCII \ character is not eligible to begin a Unicode escape. ----- Alex From joe.darcy at oracle.com Thu Jul 15 18:41:55 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 15 Jul 2021 11:41:55 -0700 Subject: FYI, maintenance review of JSR 269 API underway for Java SE 17 changes Message-ID: <47ead42b-9685-2f15-bbc5-d23d5b80f7e3@oracle.com> FYI, JSR 269, the annotation processing API covering the javax.lang.model.* and javax.annotation.processing packages, is up for maintenance review for changes being made in Java SE 17: https://jcp.org/aboutJava/communityprocess/maintenance/jsr269/index11.html -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Thu Jul 15 19:13:19 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 15 Jul 2021 12:13:19 -0700 Subject: FYI, maintenance review of JSR 269 API underway for Java SE 17 changes In-Reply-To: <47ead42b-9685-2f15-bbc5-d23d5b80f7e3@oracle.com> References: <47ead42b-9685-2f15-bbc5-d23d5b80f7e3@oracle.com> Message-ID: On 7/15/2021 11:41 AM, Joe Darcy wrote: > JSR 269, the annotation processing API covering the javax.lang.model.* > and javax.annotation.processing packages, is up for maintenance review > for changes being made in Java SE 17: > > https://jcp.org/aboutJava/communityprocess/maintenance/jsr269/index11.html One of the changes is "standard support for JEP 409: Sealed Classes", so to understand the extent of that support, I went to the JDK 17 javadoc and used the new-in-17 top level page called "NEW": https://download.java.net/java/early_access/jdk17/docs/api/new-list.html It's very easy to skim the "Added in 17" sub-tabs to discover things like `javax.lang.model.element.TypeElement.getPermittedSubclasses()` which I would not have found simply by searching for "sealed" in the web page. Alex From cushon at google.com Fri Jul 16 03:12:07 2021 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 15 Jul 2021 20:12:07 -0700 Subject: JDK-8254073, unicode escape preprocessing, and \u005C In-Reply-To: <74E0A370-673E-445A-B9B2-E5BF5B9AD3D6@oracle.com> References: <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com> <86520066-93a7-d24e-c86e-e9dda6b9bc9b@oracle.com> <2feaea08-2217-a094-93ef-fc519cab793e@oracle.com> <74E0A370-673E-445A-B9B2-E5BF5B9AD3D6@oracle.com> Message-ID: In case it's helpful, here's some more context on what I've seen of the compatibility impact. I originally noticed the change in a single project that contained three examples of \u005C\\u005D. That code is in an obsolete version of the 'stanford-parser' library, and I think that example may have been incorrect for either interpretation of the escapes. That example can be seen here: $ wget http://nlp.stanford.edu/software/stanford-parser-2011-06-23.tgz $ tar xzvf stanford-parser-2011-06-23.tgz $ grep 'u005C' ./stanford-parser-2011-06-23/src/edu/stanford/nlp/international/arabic/pipeline/DefaultLexicalMapper.java ./stanford-parser-2011-06-23/src/edu/stanford/nlp/parser/lexparser/FrenchUnknownWordModel.java I evaluated the fix in option (1) on my employer's codebase and didn't see any regressions. I also realized that another tool we use that processes Java source and implements its own unicode escape processing has been implementing the same approach as the proposed fix all along. So the difference doesn't affect a lot of code that I have visibility into, for whatever that's worth. I did some searching for occurrences of \u005C\u005C, which is an example that would be interpreted differently under the new rules, and found three of those: * javadoc in java.lang.String, where I think the intent was \\: https://github.com/openjdk/jdk/blob/e35005d5ce383ddd108096a3079b17cb0bcf76f1/src/java.base/share/classes/java/lang/String.java#L3916 * a test case in sun.net.idn: https://github.com/openjdk/jdk/blob/e35005d5ce383ddd108096a3079b17cb0bcf76f1/test/jdk/sun/net/idn/TestStringPrep.java#L131 * a test utility where the intent was \\ So based on a sample size of 3, there are more examples of \u005C\u005C where the intent was \\ than \\u005C. But either way, examples of this seem to be extremely rare. Personally I think the compatibility impact from (1) will be minimal and I'd so I'd lean towards the option that's most intuitive to specify and implement, but I defer to your judgement of the compatibility impact and if you proceed with (2) that's fine with me. Liam On Thu, Jul 15, 2021 at 10:44 AM Jim Laskey wrote: > The fall out from discussion here and via the CSR ( > https://bugs.openjdk.java.net/browse/JDK-8269290) is that we have two > choices (and noting today is RD2) > > 1) Proceed with proposed bug fix and strengthen the existing > Interpretation in the JLS. > > 2) Withdraw the CSR, fix the bug to replicate the behaviour seen prior to > JDK 16 and rework the JLS to reflect that behaviour. > > At this point, Alex and I feel the correct choice is 2). This choice has > the least risk and is likely the least disruptive. > > If we see no objections here, we will move forward early next week. > > ? Jim > > > > On Jul 6, 2021, at 8:26 PM, Alex Buckley wrote: > > (I slightly reordered the table in JDK-8269290 in support of the following > exposition.) > > Since time immemorial, X = "\u005C\\u005D" has printed `\]` on the grounds > that the six opening characters \ u 0 0 5 C form a backslash for the > purpose of counting how many backslash characters contiguously precede the > backslash in the final six characters \ u 0 0 5 D. (Two, making the > backslash in \ u 0 0 5 D eligible to begin a Unicode escape.) > > Given Y = "\u005C\u005C\u005D", it's consistent for the six opening > characters \ u 0 0 5 C to again form a backslash for the purpose of > counting how many backslash characters contiguously precede the backslash > in the middle six characters \ u 0 0 5 C. Thus, "\u005C\u005C..." is > treated the same as "\\u005C...". > > I acknowledge this is an incompatible change, but consider the > alternative. If the six opening characters *didn't* contribute a backslash > to the count for \ u 0 0 5 C in the Y case, then the same six opening > characters wouldn't contribute a backslash to the count for \ u 0 0 5 D in > the X case. (In this alternative universe, people take the rule "The > character produced by a Unicode escape does not participate in further > Unicode escapes." literally.) Thus, in the X case, there would only be one > backslash, denoted by the ASCII character, preceding the final six > characters \ u 0 0 5 D ==> the \ in \ u 0 0 5 D would not be eligible > ==> X would lex as \ \ \ u 0 0 5 D and print as `\\u005D` which is plain > wrong. > > (Maybe there is some application of the "longest possible translation" > rule from 3.2 that lets the same six opening characters become a > backslash-that-counts in X but not become a backslash-that-counts in Y. > However, I do not know how to describe that application.) > > > Here's another test case for the CSR. JDK 15 does this: > > jshell> System.out.println("\\u005D"); > \u005D > > jshell> System.out.println("\u005C\u005D"); > | Error: > | illegal escape character > | System.out.println("\u005C\u005D"); > | ^ > > With my consistency-first approach, the Z = "\u005C\u005D" case is legal, > which seems far more reasonable than illegal. The six opening characters \ > u 0 0 5 C form a backslash for the purpose of counting how many backslash > characters contiguously precede the backslash in the final six characters \ > u 0 0 5 D. (One, meaning the backslash in \ u 0 0 5 D is not eligible to > begin a Unicode escape.) The result would be \ \ u 0 0 5 D which would > print as `\u005D`. > > > Net net, I favor the correct fix -- and lots more test cases in the JCK. > > Alex > > On 7/2/2021 5:47 AM, Jim Laskey wrote: > > Just so it doesn't look like I went rogue with the bug fix ( > https://bugs.openjdk.java.net/browse/JDK-8269290 < > https://bugs.openjdk.java.net/browse/JDK-8269290>), I would like a > consensus ruling on which is the bug fix I should use; > correct fix: > interpretAsPerJLS(); > faithful fix: > if (sourceLevel <= 15) > interpretOldWay(); > else > interpretAsPerJLS(); > status quo fix: > interpretOldWay(); > I'm assuming correct fix, but others may have different assumptions. > Cheers, > -- Jim > > On Jun 25, 2021, at 4:04 PM, Alex Buckley mailto:alex.buckley at oracle.com >> wrote: > > I filed https://bugs.openjdk.java.net/browse/JDK-8269406 < > https://bugs.openjdk.java.net/browse/JDK-8269406> with some additional > discussion about what the result of the first lexical translation step is > really meant to be. > > Please take a look if you are familiar with the three-step translation > described in JLS 3.2, and care about how the input stream is processed. > > Alex > > On 6/22/2021 10:38 AM, Alex Buckley wrote: > > I am minded to extend the final note in JLS 3.3 to help people understand > the multi-level escape story in play when they experiment with Unicode > escapes. Perhaps it will also improve some javac error messages or test > cases. Let me know what you think of this: > ----- > For example, the input stream \u005cu005a results in the six characters \ > u 0 0 5 a, because 005c is the Unicode value for \. It does not result in > the character Z, which is Unicode character 005a, because the \ that > resulted from the \u005c is not interpreted as the start of a further > Unicode escape. > Note that \u005cu005a cannot be written in a string literal to denote the > six characters \ u 0 0 5 a. This is because the first two characters > resulting from translation, \ and u, are interpreted in a string literal as > an illegal escape sequence (3.10.7). > Fortunately, the rule about contiguous \ characters helps programmers to > craft input streams that denote Unicode escapes in a string literal. > Denoting the six characters \ u 0 0 5 a in a string literal simply requires > another \ to be written adjacent to the existing \, such as in "Z is > \\u005a". This works because the second \ in the input stream \\u005a is > not eligible, so the first \ and second \ are preserved as raw input > characters; they are subsequently interpreted in a string literal as the > escape sequence for a backslash, resulting in the desired six characters \ > u 0 0 5 a. Without the rule, the input stream \\u005a would be translated > as the raw input character \ followed by the Unicode escape \u005a (Z), but > \Z is an illegal escape sequence in a string literal. > The rule also allows programmers to craft input streams that denote escape > sequences in a string literal. For example, the input stream \\\u006e > results in the three characters \ \ n because the third \ is eligible and > thus \u006e is translated to n, while the first \ and second \ are > preserved as raw input characters. The three characters \ \ n are > subsequently interpreted in a string literal as \ n which denotes the > escape sequence for a linefeed. (The input stream \\\u006e may also be > written as \u005c\u005c\u006e.) > ----- > Alex > On 6/21/2021 4:41 PM, Alex Buckley wrote: > > There's no question that the first six raw input characters \ u 0 0 5 c > are identified as a Unicode escape \u005c and translated to a backslash. > > The question is whether that backslash is then treated as: > > 1. a raw input character \ that is followed by seven more raw input > characters \ \ u 0 0 5 d For these *eight* raw input characters, there > are three raw input character \'s in a row. Due to contiguous-\ counting, > the third raw input character \ is eligible to begin a Unicode escape; the > first and second pass through and you get \ \ ] which further translates > within a string literal as \] > > or > > 2. something which is independent of the subsequent seven raw input > characters \ \ u 0 0 5 d For those *seven* subsequent raw input > characters, there are two raw input character \'s in a row. Due to > contiguous-\ counting, the second raw input character \ is not eligible to > begin a Unicode escape, so all seven raw input characters pass through. You > get (including the first "independent" backslash) \ \ \ u 0 0 5 d > > > The contiguous-\ counting is due to the fact that \\ is the escape > sequence for backslash in a string literal, so we don't want too many raw \ > input character to "disappear" into Unicode escapes. > > > The JDK 15 behavior was #1. That looks correct to me. \ u 0 0 5 c becomes > a raw input character \ that cannot serve as the opening backslash for an > *immediate* Unicode escape (the classic JLS 3.3 scenario of \u005cu005a) > but that can serve as a raw input character for the purpose of skipping > over \\ pairs (the purpose of contiguous-\ counting) in order for a *later* > Unicode escape to be recognized (\u005d). > > Does "how many other \ characters contiguously precede it" refer to > preceding raw input characters, or does it refer to preceding > characters after unicode escape processing is performed on them? > > > Where JLS 3.3 says "translating the ASCII characters \u followed by four > hexadecimal digits to the UTF-16 code unit (?3.1) for the indicated > hexadecimal value", it really means "translating the ASCII characters \u > followed by four hexadecimal digits to *a raw input character which > denotes* the UTF-16 code unit (?3.1) for the indicated hexadecimal value". > > Thus, the later clause "for each raw input character that is a backslash > \, input processing must consider how many other [raw input] \ characters > contiguously precede it" can be seen more easily to include characters that > result from Unicode escape processing. > > Alex > > On 6/21/2021 2:56 PM, Jim Laskey wrote: > > "\u005C? should have been treated as a backslash. Will check into it. > > Cheers, > > ? Jim > > ?? > > On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon mailto:cushon at google.com >> wrote: > > ? > class T { > public static void main(String[] args) { > System.err.println("\u005C\\u005D"); > } > } > > Before JDK-8254073, this prints `\]`. > > After JDK-8254073, unicode escape processing results in `\\\u005D`, which > results in an 'invalid escape' error for `\u`. Was that deliberate? > > JLS 3.3 says > > for each raw input character that is a backslash \, input processing must > consider how many other \ characters contiguously precede it, separating it > from a non-\ character or the start of the input stream. If this number is > even, then the \ is eligible to begin a Unicode escape; if the number is > odd, then the \ is not eligible to begin a Unicode escape. > > > The difference is in whether `\u005C` (the unicode escape for `\`) counts > as one of the `\` preceding a valid unicode escape. > > Does "how many other \ characters contiguously precede it" refer to > preceding raw input characters, or does it refer to preceding characters > after unicode escape processing is performed on them? > > JLS 3.3 also mentions that a "character produced by a Unicode escape does > not participate in further Unicode escapes", but I'm not sure if that > applies here, since in the pre-JDK-8254073 interpretation the > unicode-escaped backslash isn't really 'participating' in the second > unicode escape. > > Thanks, > Liam > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gloriadominguez733 at gmail.com Sat Jul 17 04:10:02 2021 From: gloriadominguez733 at gmail.com (gloria Dominguez) Date: Fri, 16 Jul 2021 21:10:02 -0700 Subject: No subject Message-ID: Confirmado -------------- next part -------------- An HTML attachment was scrubbed... URL: From gloriadominguez733 at gmail.com Sat Jul 17 04:55:15 2021 From: gloriadominguez733 at gmail.com (gloria Dominguez) Date: Fri, 16 Jul 2021 21:55:15 -0700 Subject: No subject Message-ID: Aplicar lista -------------- next part -------------- An HTML attachment was scrubbed... URL: From gloriadominguez733 at gmail.com Sat Jul 17 05:35:35 2021 From: gloriadominguez733 at gmail.com (gloria Dominguez) Date: Fri, 16 Jul 2021 22:35:35 -0700 Subject: No subject Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From gloriadominguez733 at gmail.com Sun Jul 18 04:33:29 2021 From: gloriadominguez733 at gmail.com (gloria Dominguez) Date: Sat, 17 Jul 2021 21:33:29 -0700 Subject: No subject Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.java.net Sun Jul 18 20:47:10 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 18 Jul 2021 20:47:10 GMT Subject: RFR: 8269689: Update --release 17 symbol information for JDK 17 build 31 Message-ID: Usual kind of updates for the symbol information in JDK 18 to reflect changes in the JDK 17 API. Bug fixes with API changes since JDK 17 b28 include JDK-8266313, JDK-8268972, and JDK-8266269. ------------- Commit messages: - 8269689: Update --release 17 symbol information for JDK 17 build 31 Changes: https://git.openjdk.java.net/jdk/pull/4820/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4820&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269689 Stats: 6 lines in 2 files changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4820.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4820/head:pull/4820 PR: https://git.openjdk.java.net/jdk/pull/4820 From jlahoda at openjdk.java.net Mon Jul 19 07:27:53 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 19 Jul 2021 07:27:53 GMT Subject: RFR: 8269689: Update --release 17 symbol information for JDK 17 build 31 In-Reply-To: References: Message-ID: On Sun, 18 Jul 2021 19:33:20 GMT, Joe Darcy wrote: > Usual kind of updates for the symbol information in JDK 18 to reflect changes in the JDK 17 API. Bug fixes with API changes since JDK 17 b28 include JDK-8266313, JDK-8268972, and JDK-8266269. Looks good, thanks! ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4820 From ilyas.selimov at jetbrains.com Mon Jul 19 10:02:30 2021 From: ilyas.selimov at jetbrains.com (Ilyas Selimov) Date: Mon, 19 Jul 2021 17:02:30 +0700 Subject: Pattern matching for switch: Spec and Javac inconsistency regarding dominance in switch blocks Message-ID: Hello! I found a difference between dominance rules for switch blocks in spec draft ( http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210527/specs/patterns-switch-jls.html#jls-14.11.1) and its javac implementation (OpenJDK 17 build 17-ea+31-2664). Spec: > A switch label that has a pattern case label element p dominates another switch label that has a constant case label element c if either of the following is true: > - the type of c is a primitive type and its wrapper class (5.1.7) is a subtype of the erasure of the type of p. > - the type of c is a reference type and is a subtype of the erasure of the type of p. > It is a compile-time error if a switch label in a switch block dominates any switch label that follows it in the switch block. The next code compiles correctly, but it seems to contradict the rules above: void test(Integer i) { switch (i) { case Integer in && in != null: break; case 1: break; case default: break; } } Possibly p should be total for the type of selector expression like it was made for pattern-over-null dominance? Thanks, Ilyas -------------- next part -------------- An HTML attachment was scrubbed... URL: From anna.kozlova at jetbrains.com Mon Jul 19 17:00:37 2021 From: anna.kozlova at jetbrains.com (Anna Kozlova) Date: Mon, 19 Jul 2021 19:00:37 +0200 Subject: unexpected type for dummy switch on null Message-ID: Hi folks, I got an exception when compile dummy code with latest available build 31 void f() { switch (null) { case default: System.out.println(); } } jjava: java.lang.AssertionError: unexpected type: java: at jdk.compiler/com.sun.tools.javac.tree.TreeMaker.Type(TreeMaker.java:860) java: at jdk.compiler/com.sun.tools.javac.tree.TreeMaker.VarDef(TreeMaker.java:882) java: at jdk.compiler/com.sun.tools.javac.comp.TransPatterns.handleSwitch(TransPatterns.java:350) java: at jdk.compiler/com.sun.tools.javac.comp.TransPatterns.visitSwitch(TransPatterns.java:267) java: at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCSwitch.accept(JCTree.java:1294) java: at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) java: at jdk.compiler/com.sun.tools.javac.comp.TransPatterns.visitBlock(TransPatterns.java:642) java: at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1091) java: at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitMethodDef(TreeTranslator.java:150) java: at jdk.compiler/com.sun.tools.javac.comp.TransPatterns.visitMethodDef(TransPatterns.java:589) java: at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:921) java: at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) java: at jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitClassDef(TreeTranslator.java:139) java: at jdk.compiler/com.sun.tools.javac.comp.TransPatterns.visitClassDef(TransPatterns.java:669) java: at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:819) java: at jdk.compiler/com.sun.tools.javac.comp.TransPatterns.translateTopLevelClass(TransPatterns.java:698) java: at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1535) java: at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1408) java: at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) java: at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104) java: at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152) java: at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100) java: at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94) java: at org.jetbrains.jps.javac.JavacMain.compile(JavacMain.java:238) Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Jul 19 18:06:11 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Jul 2021 14:06:11 -0400 Subject: unexpected type for dummy switch on null In-Reply-To: References: Message-ID: <85b60e6a-29f4-09c9-b82f-46b4037fa63b@oracle.com> To be clear, the correct behavior would be to throw an NPE.? If the code were slightly different: ??? case null, default: ... then the correct behavior would be to print a blank line. On 7/19/2021 1:00 PM, Anna Kozlova wrote: > Hi folks, > I got an exception when compile dummy code with latest available build 31 > void f() { > switch (null) { > case default: > System.out.println(); } > } > > jjava: java.lang.AssertionError: unexpected type: > java: at > jdk.compiler/com.sun.tools.javac.tree.TreeMaker.Type(TreeMaker.java:860) > java: at > jdk.compiler/com.sun.tools.javac.tree.TreeMaker.VarDef(TreeMaker.java:882) > java: at > jdk.compiler/com.sun.tools.javac.comp.TransPatterns.handleSwitch(TransPatterns.java:350) > java: at > jdk.compiler/com.sun.tools.javac.comp.TransPatterns.visitSwitch(TransPatterns.java:267) > java: at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCSwitch.accept(JCTree.java:1294) > java: at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) > java: at > jdk.compiler/com.sun.tools.javac.comp.TransPatterns.visitBlock(TransPatterns.java:642) > java: at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1091) > java: at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitMethodDef(TreeTranslator.java:150) > java: at > jdk.compiler/com.sun.tools.javac.comp.TransPatterns.visitMethodDef(TransPatterns.java:589) > java: at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:921) > java: at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) > java: at > jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitClassDef(TreeTranslator.java:139) > java: at > jdk.compiler/com.sun.tools.javac.comp.TransPatterns.visitClassDef(TransPatterns.java:669) > java: at > jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:819) > java: at > jdk.compiler/com.sun.tools.javac.comp.TransPatterns.translateTopLevelClass(TransPatterns.java:698) > java: at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1535) > java: at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1408) > java: at > jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) > java: at > jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104) > java: at > jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152) > java: at > jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100) > java: at > jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94) > java: at org.jetbrains.jps.javac.JavacMain.compile(JavacMain.java:238) > > Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Mon Jul 19 19:13:57 2021 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 19 Jul 2021 21:13:57 +0200 Subject: unexpected type for dummy switch on null In-Reply-To: <85b60e6a-29f4-09c9-b82f-46b4037fa63b@oracle.com> References: <85b60e6a-29f4-09c9-b82f-46b4037fa63b@oracle.com> Message-ID: <1b6935cb-501b-7c3f-8ff8-2e0a789d8c68@oracle.com> Please see: https://bugs.openjdk.java.net/browse/JDK-8269113 Thanks for the report, ??? Jan On 19. 07. 21 20:06, Brian Goetz wrote: > To be clear, the correct behavior would be to throw an NPE.? If the > code were slightly different: > > ??? case null, default: ... > > then the correct behavior would be to print a blank line. > > On 7/19/2021 1:00 PM, Anna Kozlova wrote: >> Hi folks, >> I got an exception when compile dummy code with latest available build 31 >> void f() { >> switch (null) { >> case default: >> System.out.println(); } >> } >> >> jjava: java.lang.AssertionError: unexpected type: >> java: at >> jdk.compiler/com.sun.tools.javac.tree.TreeMaker.Type(TreeMaker.java:860) >> java: at >> jdk.compiler/com.sun.tools.javac.tree.TreeMaker.VarDef(TreeMaker.java:882) >> java: at >> jdk.compiler/com.sun.tools.javac.comp.TransPatterns.handleSwitch(TransPatterns.java:350) >> java: at >> jdk.compiler/com.sun.tools.javac.comp.TransPatterns.visitSwitch(TransPatterns.java:267) >> java: at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCSwitch.accept(JCTree.java:1294) >> java: at >> jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) >> java: at >> jdk.compiler/com.sun.tools.javac.comp.TransPatterns.visitBlock(TransPatterns.java:642) >> java: at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1091) >> java: at >> jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitMethodDef(TreeTranslator.java:150) >> java: at >> jdk.compiler/com.sun.tools.javac.comp.TransPatterns.visitMethodDef(TransPatterns.java:589) >> java: at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:921) >> java: at >> jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) >> java: at >> jdk.compiler/com.sun.tools.javac.tree.TreeTranslator.visitClassDef(TreeTranslator.java:139) >> java: at >> jdk.compiler/com.sun.tools.javac.comp.TransPatterns.visitClassDef(TransPatterns.java:669) >> java: at >> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:819) >> java: at >> jdk.compiler/com.sun.tools.javac.comp.TransPatterns.translateTopLevelClass(TransPatterns.java:698) >> java: at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1535) >> java: at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1408) >> java: at >> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) >> java: at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104) >> java: at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152) >> java: at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100) >> java: at >> jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94) >> java: at org.jetbrains.jps.javac.JavacMain.compile(JavacMain.java:238) >> >> Anna > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon Jul 19 16:49:14 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 19 Jul 2021 18:49:14 +0200 (CEST) Subject: @Override on a record component compiles but does not work Message-ID: <1733336209.547532.1626713354940.JavaMail.zimbra@u-pem.fr> It does not seems that @Override correctly compiles on a record but the "override" check is not done. By example, interface Named { String name(); } record Foo(@Override String name) implements Named { } actually compiles but record Foo(String name, @Override String bar) implements Named { } also compiles ?? It seems that the logic that checks if a method "overrides" another (in the general sense i.e replace another method) is not implemented if @Override is declared on a record component. regards, R?mi From forax at univ-mlv.fr Mon Jul 19 16:49:14 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 19 Jul 2021 18:49:14 +0200 (CEST) Subject: @Override on a record component compiles but does not work Message-ID: <1733336209.547532.1626713354940.JavaMail.zimbra@u-pem.fr> It does not seems that @Override correctly compiles on a record but the "override" check is not done. By example, interface Named { String name(); } record Foo(@Override String name) implements Named { } actually compiles but record Foo(String name, @Override String bar) implements Named { } also compiles ?? It seems that the logic that checks if a method "overrides" another (in the general sense i.e replace another method) is not implemented if @Override is declared on a record component. regards, R?mi From vicente.romero at oracle.com Mon Jul 19 19:54:41 2021 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 19 Jul 2021 15:54:41 -0400 Subject: @Override on a record component compiles but does not work In-Reply-To: <1733336209.547532.1626713354940.JavaMail.zimbra@u-pem.fr> References: <1733336209.547532.1626713354940.JavaMail.zimbra@u-pem.fr> Message-ID: <0c3dee4d-2baa-5bf3-9602-8c4f75067466@oracle.com> Hi Remi, According to JLS 16 9.6.4.4: ... The clause about a record class is due to the special meaning of @Override in a record declaration. Namely, it can be used to specify that a method declaration is an accessor method for a record component. Consider the following record declaration: ??? record Roo(int x) { ??????? @Override ??????????? public int x() { ??????????????? return Math.abs(x); ??????????? } ??????? } ??? } The use of @Override on the accessor method int x() ensures that if the record component x is modified or removed, then the corresponding accessor method must be modified or removed too. ... So it is OK to annotate a record component with the @Override annotation without the need for a superinterface defining an override equivalent method to exist, Thanks, Vicente On 7/19/21 12:49 PM, Remi Forax wrote: > It does not seems that @Override correctly compiles on a record but the "override" check is not done. > > By example, > interface Named { > String name(); > } > record Foo(@Override String name) implements Named { } > > actually compiles but > record Foo(String name, @Override String bar) implements Named { } > > also compiles ?? > > It seems that the logic that checks if a method "overrides" another (in the general sense i.e replace another method) is not implemented if @Override is declared on a record component. > > regards, > R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Tue Jul 20 17:04:47 2021 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 20 Jul 2021 17:04:47 +0000 Subject: @Override on a record component compiles but does not work In-Reply-To: <0c3dee4d-2baa-5bf3-9602-8c4f75067466@oracle.com> References: <1733336209.547532.1626713354940.JavaMail.zimbra@u-pem.fr> <0c3dee4d-2baa-5bf3-9602-8c4f75067466@oracle.com> Message-ID: Hi Remi, Just to back up Vicente?s reply. You?ll recall that the intent of the implicit accessor declaration is that these two record declarations are, in essence, identical: record R(@Override int x){} and record R(int x){ @Override public int x(){ return this.x; } } So, given that assumption, and the snippet that Vicente included from JLS 16.9.6.4.4 that explains that @Override has a special meaning for accessor methods, then you get the behaviour that you have observed. Thanks, Gavin On 19 Jul 2021, at 20:54, Vicente Romero > wrote: Hi Remi, According to JLS 16 9.6.4.4: ... The clause about a record class is due to the special meaning of @Override in a record declaration. Namely, it can be used to specify that a method declaration is an accessor method for a record component. Consider the following record declaration: record Roo(int x) { @Override public int x() { return Math.abs(x); } } } The use of @Override on the accessor method int x() ensures that if the record component x is modified or removed, then the corresponding accessor method must be modified or removed too. ... So it is OK to annotate a record component with the @Override annotation without the need for a superinterface defining an override equivalent method to exist, Thanks, Vicente On 7/19/21 12:49 PM, Remi Forax wrote: It does not seems that @Override correctly compiles on a record but the "override" check is not done. By example, interface Named { String name(); } record Foo(@Override String name) implements Named { } actually compiles but record Foo(String name, @Override String bar) implements Named { } also compiles ?? It seems that the logic that checks if a method "overrides" another (in the general sense i.e replace another method) is not implemented if @Override is declared on a record component. regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue Jul 20 17:26:08 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 20 Jul 2021 19:26:08 +0200 (CEST) Subject: @Override on a record component compiles but does not work In-Reply-To: References: <1733336209.547532.1626713354940.JavaMail.zimbra@u-pem.fr> <0c3dee4d-2baa-5bf3-9602-8c4f75067466@oracle.com> Message-ID: <738387686.1104793.1626801968621.JavaMail.zimbra@u-pem.fr> > From: "Gavin Bierman" > To: "Vicente Romero" > Cc: "Remi Forax" , "compiler-dev" > > Sent: Mardi 20 Juillet 2021 19:04:47 > Subject: Re: @Override on a record component compiles but does not work > Hi Remi, > Just to back up Vicente?s reply. > You?ll recall that the intent of the implicit accessor declaration is that these > two record declarations are, in essence, identical : > record R(@Override int x){} > and > record R(int x){ > @Override > public int x(){ > return this.x; > } > } > So, given that assumption, and the snippet that Vicente included from JLS > 16.9.6.4.4 that explains that @Override has a special meaning for accessor > methods, then you get the behaviour that you have observed. Thanks to both of you, I think i miss the fact that allowing @Override on an accessor also means that it makes @Override useless on components. Now, i wonder if it something that we should fix or not, only allows @Override on a component if it implements a method of an interface or it does not worth to have a special case and it's already too late. > Thanks, > Gavin regards, R?mi >> On 19 Jul 2021, at 20:54, Vicente Romero < [ mailto:vicente.romero at oracle.com | >> vicente.romero at oracle.com ] > wrote: >> Hi Remi, >> According to JLS 16 9.6.4.4: >> ... >> The clause about a record class is due to the special meaning of @Override in a >> record >> declaration. Namely, it can be used to specify that a method declaration is an >> accessor >> method for a record component. Consider the following record declaration: >> record Roo(int x) { >> @Override >> public int x() { >> return Math.abs(x); >> } >> } >> } >> The use of @Override on the accessor method int x() ensures that if the record >> component x is modified or removed, then the corresponding accessor method must >> be >> modified or removed too. >> ... >> So it is OK to annotate a record component with the @Override annotation without >> the need for a superinterface defining an override equivalent method to exist, >> Thanks, >> Vicente >> On 7/19/21 12:49 PM, Remi Forax wrote: >>> It does not seems that @Override correctly compiles on a record but the >>> "override" check is not done. >>> By example, >>> interface Named { >>> String name(); >>> } >>> record Foo(@Override String name) implements Named { } >>> actually compiles but >>> record Foo(String name, @Override String bar) implements Named { } >>> also compiles ?? >>> It seems that the logic that checks if a method "overrides" another (in the >>> general sense i.e replace another method) is not implemented if @Override is >>> declared on a record component. >>> regards, >>> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Mon Jul 19 17:13:51 2021 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 19 Jul 2021 20:13:51 +0300 Subject: Slow compilation with a lot of type inference Message-ID: Hi, I have recently submitted an Eclipse bug [1] regarding very slow compilation when a lot of type inference is required. The report includes an example case, which looks like: public static final Map DESC = Map.ofEntries( Map.entry("A", "B"), Map.entry("A", "B"), Map.entry("A", "B"), // many more of these ); The Eclipse developer shows that the slowness happens in javac as well. I understand that every entry needs to be looked at to find the type for Map.ofEntries, and the problem can be resolved by adding Map.ofEntries, but I thought it's worth asking here too. Is this considered normal behavior? [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=574732 - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilhelm at openjdk.java.net Thu Jul 22 00:02:23 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 22 Jul 2021 00:02:23 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8266347: assert(Dependencies::is_concrete_root_method(fm, ctxk) == Dependencies::is_concrete_method(m, ctxk)) failed: mismatch - 8264066: Enhance compiler validation - 8265201: JarFile.getInputStream not validating invalid signed jars - 8258432: Improve File Transfers - 8264079: Improve abstractions - 8262380: Enhance XML processing passes - 8262967: Improve Zip file support - 8264460: Improve NTLM support - 8256491: Better HTTP transport - ... and 10 more: https://git.openjdk.java.net/jdk/compare/0790f04d...025eaefb The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4863/files Stats: 517 lines in 33 files changed: 403 ins; 34 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/4863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863 PR: https://git.openjdk.java.net/jdk/pull/4863 From jwilhelm at openjdk.java.net Thu Jul 22 00:51:37 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 22 Jul 2021 00:51:37 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 282 commits: - Merge - 8271015: Split cds/SharedBaseAddress.java test into smaller parts Reviewed-by: ccheung, minqi - 8271014: Refactor HeapShared::is_archived_object() Reviewed-by: ccheung, minqi - 8270949: Make dynamically generated classes with the class file version of the current release Reviewed-by: alanb - 8269849: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects" Reviewed-by: kbarrett - 8270991: G1 Full GC always performs heap verification after JDK-8269295 Reviewed-by: iwalulya, kbarrett - 8270820: remove unused stiFileTableIndex from SDE.c Reviewed-by: cjplummer, sspitsyn - 8270147: Increase stride size allowing unrolling more loops Reviewed-by: kvn, iveresov - 8270803: Reduce CDS API verbosity Reviewed-by: minqi, ccheung - 8269933: test/jdk/javax/net/ssl/compatibility/JdkInfo incorrect verification of protocol and cipher support Reviewed-by: xuelei, rhalade - ... and 272 more: https://git.openjdk.java.net/jdk/compare/89f7998a...025eaefb ------------- Changes: https://git.openjdk.java.net/jdk/pull/4863/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=01 Stats: 55988 lines in 1158 files changed: 26162 ins; 25130 del; 4696 mod Patch: https://git.openjdk.java.net/jdk/pull/4863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863 PR: https://git.openjdk.java.net/jdk/pull/4863 From jwilhelm at openjdk.java.net Thu Jul 22 00:51:38 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 22 Jul 2021 00:51:38 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 23:52:53 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: c36755de Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/c36755dedf1a0d7ce0aeadd401e0c70ff84185e7 Stats: 517 lines in 33 files changed: 403 ins; 34 del; 80 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4863 From vicente.romero at oracle.com Thu Jul 22 02:03:14 2021 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 21 Jul 2021 22:03:14 -0400 Subject: Slow compilation with a lot of type inference In-Reply-To: References: Message-ID: <1a1fa0b8-5dae-0495-931d-bc84f579de9f@oracle.com> Hi Nir, We have done a lot of work to speed up inference, unfortunately it is always possible to generate code that will make the inference engine look bad, please file a bug in our JIRA system with all of your findings and we will get to it when possible, Thanks, Vicente On 7/19/21 1:13 PM, Nir Lisker wrote: > Hi, > > I have recently submitted an Eclipse bug [1] regarding very slow > compilation when a lot of type inference is required. The report > includes an example case, which?looks like: > > public static final Map DESC = Map.ofEntries( > ? ? Map.entry("A", "B"), > ? ? Map.entry("A", "B"), > ? ? Map.entry("A", "B"), > ? ? // many more of these > ); > > The Eclipse developer shows that the slowness happens in javac as > well. I understand that every entry needs to be looked at to find the > type for Map.ofEntries, and the problem can be resolved by adding > Map.ofEntries, but I thought it's worth asking here too. > > Is this considered normal behavior? > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=574732 > > > - Nir From maurizio.cimadamore at oracle.com Thu Jul 22 10:39:29 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 22 Jul 2021 11:39:29 +0100 Subject: Slow compilation with a lot of type inference In-Reply-To: <1a1fa0b8-5dae-0495-931d-bc84f579de9f@oracle.com> References: <1a1fa0b8-5dae-0495-931d-bc84f579de9f@oracle.com> Message-ID: <7ab96f26-314a-9f17-94bd-2f69174e4183@oracle.com> Hi, we already have entries for those: https://bugs.openjdk.java.net/browse/JDK-8152289 and https://bugs.openjdk.java.net/browse/JDK-8221301 In javac we are doing a lot of heroics to try and keep the space of inference variable as small as possible, by aggressively de-duping inference variables where possible. This strategy works well in cases like: a(b(c(d(...))))) But in cases like the ones you report (or those in the JBS issues above), which have a shape like: a(b(), c(), d(), e() ... ) We do not yet perform any de-duping, so the inference engine has to run with a very big set of (possibly very similarly looking) inference variables. Performing incorporation will end up setting similarly looking bounds on the inference variables of the outer a() call, which all have to be validated, and so on and so forth. I think de-duping cases like these is still possible, but it's a change that probably cuts much deeper into the inference engine - and we have been holding off on that when we fixed the main inference performance issue in Java 8/9, although I understand that with the Collection factories, idioms like these just got a lot more common. Cheers Maurizio On 22/07/2021 03:03, Vicente Romero wrote: > Hi Nir, > > We have done a lot of work to speed up inference, unfortunately it is > always possible to generate code that will make the inference engine > look bad, please file a bug in our JIRA system with all of your > findings and we will get to it when possible, > > Thanks, > Vicente > > On 7/19/21 1:13 PM, Nir Lisker wrote: >> Hi, >> >> I have recently submitted an Eclipse bug [1] regarding very slow >> compilation when a lot of type inference is required. The report >> includes an example case, which?looks like: >> >> public static final Map DESC = Map.ofEntries( >> ? ? Map.entry("A", "B"), >> ? ? Map.entry("A", "B"), >> ? ? Map.entry("A", "B"), >> ? ? // many more of these >> ); >> >> The Eclipse developer shows that the slowness happens in javac as >> well. I understand that every entry needs to be looked at to find the >> type for Map.ofEntries, and the problem can be resolved by adding >> Map.ofEntries, but I thought it's worth asking here too. >> >> Is this considered normal behavior? >> >> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=574732 >> >> >> - Nir > From jjg at openjdk.java.net Thu Jul 22 16:26:53 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 22 Jul 2021 16:26:53 GMT Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v6] In-Reply-To: References: Message-ID: On Tue, 20 Jul 2021 13:35:24 GMT, Jim Laskey wrote: >> \u005C Unicode escape sequence not being treated as a backslash for general escape sequences. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove comment duplicated by merge Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/126 From jlahoda at openjdk.java.net Thu Jul 22 18:30:10 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 22 Jul 2021 18:30:10 GMT Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v6] In-Reply-To: References: Message-ID: On Tue, 20 Jul 2021 13:35:24 GMT, Jim Laskey wrote: >> \u005C Unicode escape sequence not being treated as a backslash for general escape sequences. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove comment duplicated by merge Looks good. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/126 From alex.buckley at oracle.com Thu Jul 22 18:41:40 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 22 Jul 2021 11:41:40 -0700 Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v6] In-Reply-To: References: Message-ID: <06499ae9-0e88-c300-23ee-850f77aaf59f@oracle.com> I am not a Reviewer, but looking at the test UnicodeBackslash.java I recommend grouping the test case based on the number of \u005C Unicode escapes in the string literal, with a blank line between different groups. For example, swap lines 45 and 46, and have a blank line after 45 so that the tests with only one Unicode escape in four backslashes are together -- and have a comment to that effect. Without grouping and comments, this test is incomprehensible tomorrow. Alex On 7/22/2021 11:30 AM, Jan Lahoda wrote: > On Tue, 20 Jul 2021 13:35:24 GMT, Jim Laskey wrote: > >>> \u005C Unicode escape sequence not being treated as a backslash for general escape sequences. >> >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove comment duplicated by merge > > Looks good. > > ------------- > > Marked as reviewed by jlahoda (Reviewer). > > PR: https://git.openjdk.java.net/jdk17/pull/126 > From darcy at openjdk.java.net Thu Jul 22 18:49:07 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 22 Jul 2021 18:49:07 GMT Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v6] In-Reply-To: References: Message-ID: On Tue, 20 Jul 2021 13:35:24 GMT, Jim Laskey wrote: >> \u005C Unicode escape sequence not being treated as a backslash for general escape sequences. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove comment duplicated by merge Please revise the CSR for the updated change in behavior. ------------- PR: https://git.openjdk.java.net/jdk17/pull/126 From jjg at openjdk.java.net Thu Jul 22 18:56:09 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 22 Jul 2021 18:56:09 GMT Subject: Integrated: JDK-8249634: doclint should report implicit constructor as missing javadoc comments In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 17:48:48 GMT, Jonathan Gibbons wrote: > Please review a simple update to doclint, to generate messages for the "effectively missing" comment on default constructors on "normal" classes (not enums classes or record classes.) > > The change does affect a bunch of tests, mostly doclint tests, which all use atypical "toy" classes to host the comments to be tested, and which generally do not have explicit constructors ... and so trigger the new warning about using default constructors. > > There is no one solution applied to all tests. The general theme of the changes is to minimize the changes, and in almost all cases to avoid changing any "golden files" or "expected output". > > The following techniques are used to modify tests: > > where it does not significantly interact with other test options, disable the check for missing comments when that is not the primary function of the test > where it would not affect any line numbers in any expected output, add an explicit no-args constructor at the end of the class body > add an explicit no-args constructor on the same line as the opening { of the class body (i.e.in order not to change line numbers in reference output) This pull request has now been integrated. Changeset: c1c40489 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/c1c404896ca2791ad348a4cf482beb2c2ad98464 Stats: 235 lines in 76 files changed: 121 ins; 4 del; 110 mod 8249634: doclint should report implicit constructor as missing javadoc comments Reviewed-by: hannesw ------------- PR: https://git.openjdk.java.net/jdk/pull/4695 From duke at openjdk.java.net Thu Jul 22 20:03:08 2021 From: duke at openjdk.java.net (duke) Date: Thu, 22 Jul 2021 20:03:08 GMT Subject: Withdrawn: 8267312: Resolve should use generated diagnostic factories In-Reply-To: References: Message-ID: On Tue, 18 May 2021 11:07:18 GMT, Maurizio Cimadamore wrote: > This patch allows Resolve to use more static diagnostic factories. Resolution errors support generation of diagnostics. This generation is very flexible and allows creating either a toplevel (error or warning) diagnostic, or a nested (fragment) diagostic. To support this, many resolution diagnostics in javac define some "overloads" in compiler.properties - e.g. > > > # 0: message segment > compiler.err.prob.found.req=... > # 0: message segment > compiler.misc.prob.found.req=... > # 0: message segment, 1: type, 2: type > compiler.warn.prob.found.req=... > > > To support switching from one diagnostic kind to another, this patch adds a new method on `DiagnosticInfo`, namely `toType(DiagnosticType)`. The default implementation of this method will simply check that the type is identical to that of the current diagnostic info, and throw otherwise. > > This patch modifies the build-time step to construct diagnostic factories, so that, whenever a diagnostic overload is detected, the `toType` method is overridden, and the right constants/factories are returned/called depending on the requested diagnostic type. For instance, the factory for the `prob.found.req` key will look as follows in the generated code: > > > /** > * compiler.err.prob.found.req=\ > * incompatible types: {0} > */ > public static Error ProbFoundReq(Fragment arg0) { > return new Error("compiler", "prob.found.req", arg0) { > public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) { > return switch (kind) { > case ERROR -> this; > case WARNING -> throw new AssertionError("Unsupported kind: " + kind); > case FRAGMENT -> Fragments.ProbFoundReq(arg0); > case NOTE -> throw new AssertionError("Unsupported kind: " + kind); > }; > } > }; > } > > > As you can see, the build time process correctly detects all diagnostic overloads and generate some code to convert one diagnostic info to another. Note that in this case, only two overloads are detected (`err` and `misc`), given that `warn` has a different type comment so not, technically speaking, an overload. > > With this support it is relatively easy to go back to Resolve and update most of the resolution errors to use the generated factories. > > The only case I have not dealt with is the "cannot.resolve" diagnostic, which has many variants: `{ var, method, generic method } x { location, no location }`. To use the factories effectively here a change in the way the diagnostic is structured is required, but doing so, while trivial, will cause many change in the golden test files, so I held off these changes for now, and will come back later to this. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4089 From alex.buckley at oracle.com Thu Jul 22 20:25:59 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 22 Jul 2021 13:25:59 -0700 Subject: JDK-8254073, unicode escape preprocessing, and \u005C In-Reply-To: References: <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com> <86520066-93a7-d24e-c86e-e9dda6b9bc9b@oracle.com> <2feaea08-2217-a094-93ef-fc519cab793e@oracle.com> <74E0A370-673E-445A-B9B2-E5BF5B9AD3D6@oracle.com> Message-ID: <3f128771-6449-e236-839b-46acd3e875aa@oracle.com> Many thanks for this analysis Liam. We analyzed a corpus that we use internally for javac experiments. Enough programs assume that \u005C\u005C means \\ that we are loathe to make it mean something else in 17, no matter how much the idea of "something else" is appealing because it would streamline the JLS or simplify the javac implementation. The case of \u005C\\u005D is more straightforward because it translated to \\] both in javac 15 and (with some generosity of intent) in the JLS. Accordingly, we're picking option 2 -- we'll fix the JLS to fully explain the javac 15 behavior (including why \u005C\u005C means \\ and not \\u005C), and fix javac 17 to treat \u005C\\u005D like javac 15 did. Alex On 7/15/2021 8:12 PM, Liam Miller-Cushon wrote: > In case it's helpful, here's some more context on what I've seen of the > compatibility impact. > > I originally noticed the change in a single project that contained three > examples of \u005C\\u005D. That code is in an obsolete version of the > 'stanford-parser' library, and I think that example may have been > incorrect for either interpretation of the escapes. That example can be > seen here: > > $ wget http://nlp.stanford.edu/software/stanford-parser-2011-06-23.tgz > > $ tar xzvf stanford-parser-2011-06-23.tgz > $ grep 'u005C' > ./stanford-parser-2011-06-23/src/edu/stanford/nlp/international/arabic/pipeline/DefaultLexicalMapper.java > ./stanford-parser-2011-06-23/src/edu/stanford/nlp/parser/lexparser/FrenchUnknownWordModel.java > > I evaluated the fix in option (1) on my employer's codebase and didn't > see any regressions. I also realized that another tool we use that > processes Java source and implements its own unicode escape processing > has been implementing the same approach as the proposed fix all along. > So the difference doesn't affect a lot of code that I have visibility > into, for whatever that's worth. > > I did some searching for occurrences of \u005C\u005C, which is an > example that would be interpreted differently under the new rules, and > found three of those: > > * javadoc in java.lang.String, where I think the intent was \\: > https://github.com/openjdk/jdk/blob/e35005d5ce383ddd108096a3079b17cb0bcf76f1/src/java.base/share/classes/java/lang/String.java#L3916 > > > * a test case in sun.net.idn: > https://github.com/openjdk/jdk/blob/e35005d5ce383ddd108096a3079b17cb0bcf76f1/test/jdk/sun/net/idn/TestStringPrep.java#L131 > > > * a test utility where the intent was \\ > > So based on a sample size of 3, there are more examples of \u005C\u005C > where the intent was \\ than \\u005C. But either way, examples of this > seem to be extremely rare. > > Personally I think the compatibility impact from (1) will be minimal and > I'd so I'd lean towards the option that's most intuitive to specify and > implement, but I defer to your judgement of the compatibility impact and > if you proceed with (2) that's fine with me. > > Liam > > On Thu, Jul 15, 2021 at 10:44 AM Jim Laskey > wrote: > > The fall out from discussion here and via the CSR > (https://bugs.openjdk.java.net/browse/JDK-8269290 > ) is that we have > two choices (and noting today is RD2) > > 1) Proceed with proposed bug fix and strengthen?the existing > Interpretation in the JLS. > > 2) Withdraw the CSR, fix the bug to replicate the behaviour seen > prior to JDK 16 and rework the JLS to reflect that behaviour. > > At this point, Alex and I feel the correct choice is 2). This choice > has the least risk and is likely the least disruptive. > > If we see no objections here, we will move forward early next week. > > ? Jim > > > >> On Jul 6, 2021, at 8:26 PM, Alex Buckley > > wrote: >> >> (I slightly reordered the table in JDK-8269290 in support of the >> following exposition.) >> >> Since time immemorial, X = "\u005C\\u005D" has printed `\]` on the >> grounds that the six opening characters \ u 0 0 5 C form a >> backslash for the purpose of counting how many backslash >> characters contiguously precede the backslash in the final six >> characters \ u 0 0 5 D. (Two, making the backslash in \ u 0 0 5 D >> eligible to begin a Unicode escape.) >> >> Given Y = "\u005C\u005C\u005D", it's consistent for the six >> opening characters \ u 0 0 5 C to again form a backslash for the >> purpose of counting how many backslash characters contiguously >> precede the backslash in the middle six characters \ u 0 0 5 C. >> Thus, "\u005C\u005C..." is treated the same as "\\u005C...". >> >> I acknowledge this is an incompatible change, but consider the >> alternative. If the six opening characters *didn't* contribute a >> backslash to the count for \ u 0 0 5 C in the Y case, then the >> same six opening characters wouldn't contribute a backslash to the >> count for \ u 0 0 5 D in the X case. (In this alternative >> universe, people take the rule "The character produced by a >> Unicode escape does not participate in further Unicode escapes." >> literally.) Thus, in the X case, there would only be one >> backslash, denoted by the ASCII character, preceding the final six >> characters \ u 0 0 5 D ?==> ?the \ in \ u 0 0 5 D would not be >> eligible ?==> ?X would lex as \ \ \ u 0 0 5 D and print as >> `\\u005D` which is plain wrong. >> >> (Maybe there is some application of the "longest possible >> translation" rule from 3.2 that lets the same six opening >> characters become a backslash-that-counts in X but not become a >> backslash-that-counts in Y. However, I do not know how to describe >> that application.) >> >> >> Here's another test case for the CSR. JDK 15 does this: >> >> jshell> System.out.println("\\u005D"); >> \u005D >> >> jshell> System.out.println("\u005C\u005D"); >> | ?Error: >> | ?illegal escape character >> | ?System.out.println("\u005C\u005D"); >> | ????????????????????????????????^ >> >> With my consistency-first approach, the Z = "\u005C\u005D" case is >> legal, which seems far more reasonable than illegal. The six >> opening characters \ u 0 0 5 C form a backslash for the purpose of >> counting how many backslash characters contiguously precede the >> backslash in the final six characters \ u 0 0 5 D. (One, meaning >> the backslash in \ u 0 0 5 D is not eligible to begin a Unicode >> escape.) The result would be \ \ u 0 0 5 D which would print as >> `\u005D`. >> >> >> Net net, I favor the correct fix -- and lots more test cases in >> the JCK. >> >> Alex >> >> On 7/2/2021 5:47 AM, Jim Laskey wrote: >>> Just so it doesn't look like I went rogue with the bug fix >>> (https://bugs.openjdk.java.net/browse/JDK-8269290 >>> >>> >> >), I would >>> like a consensus ruling on which is the?bug?fix I should use; >>> correct fix: >>> interpretAsPerJLS(); >>> faithful fix: >>> if (sourceLevel <= 15) >>> ? ? interpretOldWay(); >>> ? ? ? ? else >>> ? ? interpretAsPerJLS(); >>> status quo fix: >>> interpretOldWay(); >>> I'm assuming correct fix, but others may have different assumptions. >>> Cheers, >>> -- Jim >>>> On Jun 25, 2021, at 4:04 PM, Alex Buckley >>>> >>>> >>> >> wrote: >>>> >>>> I filed https://bugs.openjdk.java.net/browse/JDK-8269406 >>>> >>>> >>> > with some >>>> additional discussion about what the result of the first lexical >>>> translation step is really meant to be. >>>> >>>> Please take a look if you are familiar with the three-step >>>> translation described in JLS 3.2, and care about how the input >>>> stream is processed. >>>> >>>> Alex >>>> >>>> On 6/22/2021 10:38 AM, Alex Buckley wrote: >>>>> I am minded to extend the final note in JLS 3.3 to help people >>>>> understand the multi-level escape story in play when they >>>>> experiment with Unicode escapes. Perhaps it will also improve >>>>> some javac error messages or test cases. Let me know what you >>>>> think of this: >>>>> ----- >>>>> For example, the input stream \u005cu005a results in the six >>>>> characters \ u 0 0 5 a, because 005c is the Unicode value for >>>>> \. It does not result in the character Z, which is Unicode >>>>> character 005a, because the \ that resulted from the \u005c is >>>>> not interpreted as the start of a further Unicode escape. >>>>> Note that \u005cu005a cannot be written in a string literal to >>>>> denote the six characters \ u 0 0 5 a. This is because the >>>>> first two characters resulting from translation, \ and u, are >>>>> interpreted in a string literal as an illegal escape sequence >>>>> (3.10.7). >>>>> Fortunately, the rule about contiguous \ characters helps >>>>> programmers to craft input streams that denote Unicode escapes >>>>> in a string literal. Denoting the six characters \ u 0 0 5 a in >>>>> a string literal simply requires another \ to be written >>>>> adjacent to the existing \, such as in "Z is \\u005a". This >>>>> works because the second \ in the input stream \\u005a is not >>>>> eligible, so the first \ and second \ are preserved as raw >>>>> input characters; they are subsequently interpreted in a string >>>>> literal as the escape sequence for a backslash, resulting in >>>>> the desired six characters \ u 0 0 5 a. Without the rule, the >>>>> input stream \\u005a would be translated as the raw input >>>>> character \ followed by the Unicode escape \u005a (Z), but \Z >>>>> is an illegal escape sequence in a string literal. >>>>> The rule also allows programmers to craft input streams that >>>>> denote escape sequences in a string literal. For example, the >>>>> input stream \\\u006e results in the three characters \ \ n >>>>> because the third \ is eligible and thus \u006e is translated >>>>> to n, while the first \ and second \ are preserved as raw input >>>>> characters. The three characters \ \ n are subsequently >>>>> interpreted in a string literal as \ n which denotes the escape >>>>> sequence for a linefeed. (The input stream \\\u006e may also be >>>>> written as \u005c\u005c\u006e.) >>>>> ----- >>>>> Alex >>>>> On 6/21/2021 4:41 PM, Alex Buckley wrote: >>>>>> There's no question that the first six raw input characters \ >>>>>> u 0 0 5 c are identified as a Unicode escape \u005c and >>>>>> translated to a backslash. >>>>>> >>>>>> The question is whether that backslash is then treated as: >>>>>> >>>>>> 1. a raw input character \ that is followed by seven more raw >>>>>> input characters \ \ u 0 0 5 d?? For these *eight* raw input >>>>>> characters, there are three raw input character \'s in a row. >>>>>> Due to contiguous-\ counting, the third raw input character \ >>>>>> is eligible to begin a Unicode escape; the first and second >>>>>> pass through and you get \ \ ] which further translates within >>>>>> a string literal as \] >>>>>> >>>>>> or >>>>>> >>>>>> 2. something which is independent of the subsequent seven raw >>>>>> input characters \ \ u 0 0 5 d?? For those *seven* subsequent >>>>>> raw input characters, there are two raw input character \'s in >>>>>> a row. Due to contiguous-\ counting, the second raw input >>>>>> character \ is not eligible to begin a Unicode escape, so all >>>>>> seven raw input characters pass through. You get (including >>>>>> the first "independent" backslash) \ \ \ u 0 0 5 d >>>>>> >>>>>> >>>>>> The contiguous-\ counting is due to the fact that \\ is the >>>>>> escape sequence for backslash in a string literal, so we don't >>>>>> want too many raw \ input character to "disappear" into >>>>>> Unicode escapes. >>>>>> >>>>>> >>>>>> The JDK 15 behavior was #1. That looks correct to me. \ u 0 0 >>>>>> 5 c becomes a raw input character \ that cannot serve as the >>>>>> opening backslash for an *immediate* Unicode escape (the >>>>>> classic JLS 3.3 scenario of \u005cu005a) but that can serve as >>>>>> a raw input character for the purpose of skipping over \\ >>>>>> pairs (the purpose of contiguous-\ counting) in order for a >>>>>> *later* Unicode escape to be recognized (\u005d). >>>>>> >>>>>>> Does "how many other \ characters contiguously precede it" >>>>>>> refer to >>>>>>> preceding raw input characters, or does it refer to preceding >>>>>>> characters after unicode escape processing is performed on them? >>>>>> >>>>>> Where JLS 3.3 says "translating the ASCII characters \u >>>>>> followed by four hexadecimal digits to the UTF-16 code unit >>>>>> (?3.1) for the indicated hexadecimal value", it really means >>>>>> "translating the ASCII characters \u followed by four >>>>>> hexadecimal digits to *a raw input character which denotes* >>>>>> the UTF-16 code unit (?3.1) for the indicated hexadecimal value". >>>>>> >>>>>> Thus, the later clause "for each raw input character that is a >>>>>> backslash \, input processing must consider how many other >>>>>> [raw input] \ characters contiguously precede it" can be seen >>>>>> more easily to include characters that result from Unicode >>>>>> escape processing. >>>>>> >>>>>> Alex >>>>>> >>>>>> On 6/21/2021 2:56 PM, Jim Laskey wrote: >>>>>>> "\u005C? should have been treated as a backslash. Will check >>>>>>> into it. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> ? Jim >>>>>>> >>>>>>> ?? >>>>>>> >>>>>>>> On Jun 21, 2021, at 6:28 PM, Liam Miller-Cushon >>>>>>>> >>>>>>>> >> wrote: >>>>>>>> >>>>>>>> ? >>>>>>>> class T { >>>>>>>> ?? public static void main(String[] args) { >>>>>>>> ???? System.err.println("\u005C\\u005D"); >>>>>>>> ?? } >>>>>>>> } >>>>>>>> >>>>>>>> Before JDK-8254073, this prints `\]`. >>>>>>>> >>>>>>>> After JDK-8254073, unicode escape processing results in >>>>>>>> `\\\u005D`, which results in an 'invalid escape' error for >>>>>>>> `\u`. Was that deliberate? >>>>>>>> >>>>>>>> JLS 3.3 says >>>>>>>> >>>>>>>>> for each raw input character that is a backslash \, input >>>>>>>>> processing must consider how many other \ characters >>>>>>>>> contiguously precede it, separating it from a non-\ >>>>>>>>> character or the start of the input stream. If this number >>>>>>>>> is even, then the \ is eligible to begin a Unicode escape; >>>>>>>>> if the number is odd, then the \ is not eligible to begin a >>>>>>>>> Unicode escape. >>>>>>>> >>>>>>>> The difference is in whether `\u005C` (the unicode escape >>>>>>>> for `\`) counts as one of the `\` preceding a valid unicode >>>>>>>> escape. >>>>>>>> >>>>>>>> Does "how many other \ characters contiguously precede it" >>>>>>>> refer to preceding raw input characters, or does it refer to >>>>>>>> preceding characters after unicode escape processing is >>>>>>>> performed on them? >>>>>>>> >>>>>>>> JLS 3.3 also mentions that a "character produced by a >>>>>>>> Unicode escape does not participate in further Unicode >>>>>>>> escapes", but I'm not sure if that applies here, since in >>>>>>>> the pre-JDK-8254073 interpretation the unicode-escaped >>>>>>>> backslash isn't really 'participating' in the second unicode >>>>>>>> escape. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Liam > From dcubed at openjdk.java.net Thu Jul 22 20:37:36 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 20:37:36 GMT Subject: RFR: 8271161: [BACKOUT] JDK-8249634 doclint should report implicit constructor as missing javadoc comments Message-ID: This reverts commit c1c404896ca2791ad348a4cf482beb2c2ad98464. ------------- Commit messages: - Revert "8249634: doclint should report implicit constructor as missing javadoc comments" Changes: https://git.openjdk.java.net/jdk/pull/4880/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4880&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271161 Stats: 235 lines in 76 files changed: 4 ins; 121 del; 110 mod Patch: https://git.openjdk.java.net/jdk/pull/4880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4880/head:pull/4880 PR: https://git.openjdk.java.net/jdk/pull/4880 From dcubed at openjdk.java.net Thu Jul 22 20:52:05 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 20:52:05 GMT Subject: RFR: 8271161: [BACKOUT] JDK-8249634 doclint should report implicit constructor as missing javadoc comments In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 20:27:38 GMT, Daniel D. Daugherty wrote: > This reverts commit c1c404896ca2791ad348a4cf482beb2c2ad98464. The Mach5 Tier1 job has PASSed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4880 From iignatyev at openjdk.java.net Thu Jul 22 20:57:06 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Jul 2021 20:57:06 GMT Subject: RFR: 8271161: [BACKOUT] JDK-8249634 doclint should report implicit constructor as missing javadoc comments In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 20:27:38 GMT, Daniel D. Daugherty wrote: > This reverts commit c1c404896ca2791ad348a4cf482beb2c2ad98464. Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4880 From joe.darcy at oracle.com Thu Jul 22 20:59:44 2021 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 22 Jul 2021 13:59:44 -0700 Subject: RFR: 8271161: [BACKOUT] JDK-8249634 doclint should report implicit constructor as missing javadoc comments In-Reply-To: References: Message-ID: <3c023ce8-fa52-a3df-e0f3-8ed3fb9a07cc@oracle.com> If there is only one test failing, I'd rather the single test be problem listed rather than the patch being backed out. Thanks, -Joe On 7/22/2021 1:57 PM, Igor Ignatyev wrote: > On Thu, 22 Jul 2021 20:27:38 GMT, Daniel D. Daugherty wrote: > >> This reverts commit c1c404896ca2791ad348a4cf482beb2c2ad98464. > Marked as reviewed by iignatyev (Reviewer). > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4880 From prappo at openjdk.java.net Thu Jul 22 21:07:06 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 22 Jul 2021 21:07:06 GMT Subject: RFR: 8271161: [BACKOUT] JDK-8249634 doclint should report implicit constructor as missing javadoc comments In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 20:27:38 GMT, Daniel D. Daugherty wrote: > This reverts commit c1c404896ca2791ad348a4cf482beb2c2ad98464. I think I know where the problem is: a hardcoded file separator, which is system dependent. Did the original patch for 8249634 fail on a Windows machine? ------------- PR: https://git.openjdk.java.net/jdk/pull/4880 From dcubed at openjdk.java.net Thu Jul 22 21:11:03 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 21:11:03 GMT Subject: RFR: 8271161: [BACKOUT] JDK-8249634 doclint should report implicit constructor as missing javadoc comments In-Reply-To: References: Message-ID: <4JUvwxYB9R4kbvjeJQOS55ZCJDHo1QaJyftiAVSC_kA=.1a7f5c82-1e39-43bd-8819-f14261c834e9@github.com> On Thu, 22 Jul 2021 20:27:38 GMT, Daniel D. Daugherty wrote: > This reverts commit c1c404896ca2791ad348a4cf482beb2c2ad98464. The fix for: JDK-8249634 doclint should report implicit constructor as missing javadoc comments failed on every OS in Mach5 Tier1. Not just Windows. This patch was clearly not properly tested before being integrated. A [BACKOUT] is appropriate in this situation. ------------- PR: https://git.openjdk.java.net/jdk/pull/4880 From dcubed at openjdk.java.net Thu Jul 22 21:19:07 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 21:19:07 GMT Subject: RFR: 8271161: [BACKOUT] JDK-8249634 doclint should report implicit constructor as missing javadoc comments In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 20:27:38 GMT, Daniel D. Daugherty wrote: > This reverts commit c1c404896ca2791ad348a4cf482beb2c2ad98464. @jonathan-gibbons has said that he is okay with a [BACKOUT] or a ProblemListing. The [BACKOUT] is tested and ready so I'm going with it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4880 From dcubed at openjdk.java.net Thu Jul 22 21:19:07 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 22 Jul 2021 21:19:07 GMT Subject: Integrated: 8271161: [BACKOUT] JDK-8249634 doclint should report implicit constructor as missing javadoc comments In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 20:27:38 GMT, Daniel D. Daugherty wrote: > This reverts commit c1c404896ca2791ad348a4cf482beb2c2ad98464. This pull request has now been integrated. Changeset: 9b93d816 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/9b93d816c182278427ef76ee803cc91c2d8b4223 Stats: 235 lines in 76 files changed: 4 ins; 121 del; 110 mod 8271161: [BACKOUT] JDK-8249634 doclint should report implicit constructor as missing javadoc comments Reviewed-by: iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/4880 From prappo at openjdk.java.net Thu Jul 22 21:27:09 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 22 Jul 2021 21:27:09 GMT Subject: RFR: 8271161: [BACKOUT] JDK-8249634 doclint should report implicit constructor as missing javadoc comments In-Reply-To: <4JUvwxYB9R4kbvjeJQOS55ZCJDHo1QaJyftiAVSC_kA=.1a7f5c82-1e39-43bd-8819-f14261c834e9@github.com> References: <4JUvwxYB9R4kbvjeJQOS55ZCJDHo1QaJyftiAVSC_kA=.1a7f5c82-1e39-43bd-8819-f14261c834e9@github.com> Message-ID: On Thu, 22 Jul 2021 21:08:31 GMT, Daniel D. Daugherty wrote: > This patch was clearly not properly tested before being integrated. It seems that the patch was integrated without prior synchronization with the mainline, which had diverged in the relevant areas since the patch was last updated. And no, it seems that the failure has nothing to do with the file separator. Sorry for the noise. ------------- PR: https://git.openjdk.java.net/jdk/pull/4880 From alex.buckley at oracle.com Thu Jul 22 22:12:33 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 22 Jul 2021 15:12:33 -0700 Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v6] In-Reply-To: <06499ae9-0e88-c300-23ee-850f77aaf59f@oracle.com> References: <06499ae9-0e88-c300-23ee-850f77aaf59f@oracle.com> Message-ID: Recommend the grouping below. I changed only the order of tests, and added the x.y comments; I did not change any inputs or outputs, which all looked correct. (3.6 and 4.2 are the most interesting IMO.) ----- /* 1.1 */ test("\\]", "\\]"); /* 1.2 */ test("\u005C\]", "\\]"); /* 1.3 */ test("\\u005C]", "\\u005C]"); /* 1.4 */ test("\u005C\u005C]", "\\]"); /* 2.1 */ test("\\\\]", "\\\\]"); /* 2.2 */ test("\u005C\\\]", "\\\\]"); /* 2.3 */ test("\\u005C\\]", "\\u005C\\]"); /* 2.4 */ test("\\\u005C\]", "\\\\]"); /* 2.5 */ test("\\\\u005C]", "\\\\u005C]"); /* 3.1 */ test("\u005C\u005C\\]", "\\\\]"); /* 3.2 */ test("\u005C\\u005C\]", "\\\\]"); /* 3.3 */ test("\u005C\\\u005C]", "\\\\u005C]"); /* 3.4 */ test("\\u005C\u005C\]", "\\u005C\\]"); /* 3.5 */ test("\\u005C\\u005C]", "\\u005C\\u005C]"); /* 3.6 */ test("\\\u005C\u005C]", "\\\\]"); /* 4.1 */ test("\u005C\u005C\u005C\]", "\\\\]"); /* 4.2 */ test("\u005C\\u005C\u005C]", "\\\\]"); /* 4.3 */ test("\u005C\u005C\\u005C]", "\\\\u005C]"); /* 4.4 */ test("\\u005C\u005C\u005C]", "\\u005C\\]"); /* 5.1 */ test("\u005C\u005C\u005C\u005C]", "\\\\]"); ----- Alex On 7/22/2021 11:41 AM, Alex Buckley wrote: > I am not a Reviewer, but looking at the test UnicodeBackslash.java I > recommend grouping the test case based on the number of \u005C Unicode > escapes in the string literal, with a blank line between different > groups. For example, swap lines 45 and 46, and have a blank line after > 45 so that the tests with only one Unicode escape in four backslashes > are together -- and have a comment to that effect. Without grouping and > comments, this test is incomprehensible tomorrow. > > Alex > > On 7/22/2021 11:30 AM, Jan Lahoda wrote: >> On Tue, 20 Jul 2021 13:35:24 GMT, Jim Laskey wrote: >> >>>> \u005C Unicode escape sequence not being treated as a backslash for >>>> general escape sequences. >>> >>> Jim Laskey has updated the pull request incrementally with one >>> additional commit since the last revision: >>> >>> ?? Remove comment duplicated by merge >> >> Looks good. >> >> ------------- >> >> Marked as reviewed by jlahoda (Reviewer). >> >> PR: https://git.openjdk.java.net/jdk17/pull/126 >> From john.r.rose at oracle.com Thu Jul 22 22:59:22 2021 From: john.r.rose at oracle.com (John Rose) Date: Thu, 22 Jul 2021 22:59:22 +0000 Subject: JDK-8254073, unicode escape preprocessing, and \u005C In-Reply-To: <3f128771-6449-e236-839b-46acd3e875aa@oracle.com> References: <86DC9BD0-1DDB-40D8-A46D-43A9C72EBFA9@oracle.com> <86520066-93a7-d24e-c86e-e9dda6b9bc9b@oracle.com> <2feaea08-2217-a094-93ef-fc519cab793e@oracle.com> <74E0A370-673E-445A-B9B2-E5BF5B9AD3D6@oracle.com> <3f128771-6449-e236-839b-46acd3e875aa@oracle.com> Message-ID: FWIW I think it?s OK to document the long-standing behavior as correct. Do proceed! For me this is a lesson in how the most carefully conceived escape conventions can have unintentional consequences in dark corners. That is why I think there?s still room for improvement, not in the JLS, but in the behavior of the processors of the JLS. So to track my earlier suggestion for a lint rule to flag invidious unicode escapes like \u005c and \u0020, I filed: https://bugs.openjdk.java.net/browse/JDK-8271171 ? John From darcy at openjdk.java.net Fri Jul 23 04:22:08 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 23 Jul 2021 04:22:08 GMT Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v4] In-Reply-To: <9mR4ch0M_TVBqJZ4FM0WfALojQ3D0ihJwfYm9Go-BLo=.01858a08-0d17-4a8f-b210-59e40b234b6e@github.com> References: <9mR4ch0M_TVBqJZ4FM0WfALojQ3D0ihJwfYm9Go-BLo=.01858a08-0d17-4a8f-b210-59e40b234b6e@github.com> Message-ID: On Tue, 20 Jul 2021 12:20:09 GMT, Jim Laskey wrote: >> Jim Laskey 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 four additional commits since the last revision: >> >> - Merge branch 'master' into 8269150 >> - Updated the test to include all combinations >> - Merge branch 'master' into 8269150 >> - Correct unicode escape handling in UnicodeReader, added test > > The fix has been revised to use the jdk15 (and before) logic. The JLS will be updated to clarify the fuzziness in this area. @JimLaskey , please describe in text what the intended semantics are now for the escape processing. Thanks. ------------- PR: https://git.openjdk.java.net/jdk17/pull/126 From jlaskey at openjdk.java.net Fri Jul 23 13:14:37 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 23 Jul 2021 13:14:37 GMT Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v7] In-Reply-To: References: Message-ID: > \u005C Unicode escape sequence not being treated as a backslash for general escape sequences. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update UnicodeBackslash test to be easier to follow ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/126/files - new: https://git.openjdk.java.net/jdk17/pull/126/files/67efad99..cfc1614c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=126&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=126&range=05-06 Stats: 28 lines in 1 file changed: 3 ins; 2 del; 23 mod Patch: https://git.openjdk.java.net/jdk17/pull/126.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/126/head:pull/126 PR: https://git.openjdk.java.net/jdk17/pull/126 From james.laskey at oracle.com Fri Jul 23 13:17:30 2021 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 23 Jul 2021 13:17:30 +0000 Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v6] In-Reply-To: References: <06499ae9-0e88-c300-23ee-850f77aaf59f@oracle.com> Message-ID: <6FFB4841-E568-4121-B7BC-438E9863AF17@oracle.com> PR updated with changes to the UnicodeBackslash.java test. https://github.com/openjdk/jdk17/pull/126 > On Jul 22, 2021, at 7:12 PM, Alex Buckley wrote: > > Recommend the grouping below. I changed only the order of tests, and added the x.y comments; I did not change any inputs or outputs, which all looked correct. (3.6 and 4.2 are the most interesting IMO.) > > ----- > /* 1.1 */ test("\\]", "\\]"); > /* 1.2 */ test("\u005C\]", "\\]"); > /* 1.3 */ test("\\u005C]", "\\u005C]"); > /* 1.4 */ test("\u005C\u005C]", "\\]"); > > /* 2.1 */ test("\\\\]", "\\\\]"); > /* 2.2 */ test("\u005C\\\]", "\\\\]"); > /* 2.3 */ test("\\u005C\\]", "\\u005C\\]"); > /* 2.4 */ test("\\\u005C\]", "\\\\]"); > /* 2.5 */ test("\\\\u005C]", "\\\\u005C]"); > > /* 3.1 */ test("\u005C\u005C\\]", "\\\\]"); > /* 3.2 */ test("\u005C\\u005C\]", "\\\\]"); > /* 3.3 */ test("\u005C\\\u005C]", "\\\\u005C]"); > /* 3.4 */ test("\\u005C\u005C\]", "\\u005C\\]"); > /* 3.5 */ test("\\u005C\\u005C]", "\\u005C\\u005C]"); > /* 3.6 */ test("\\\u005C\u005C]", "\\\\]"); > > /* 4.1 */ test("\u005C\u005C\u005C\]", "\\\\]"); > /* 4.2 */ test("\u005C\\u005C\u005C]", "\\\\]"); > /* 4.3 */ test("\u005C\u005C\\u005C]", "\\\\u005C]"); > /* 4.4 */ test("\\u005C\u005C\u005C]", "\\u005C\\]"); > > /* 5.1 */ test("\u005C\u005C\u005C\u005C]", "\\\\]"); > ----- > > Alex > > On 7/22/2021 11:41 AM, Alex Buckley wrote: >> I am not a Reviewer, but looking at the test UnicodeBackslash.java I recommend grouping the test case based on the number of \u005C Unicode escapes in the string literal, with a blank line between different groups. For example, swap lines 45 and 46, and have a blank line after 45 so that the tests with only one Unicode escape in four backslashes are together -- and have a comment to that effect. Without grouping and comments, this test is incomprehensible tomorrow. >> Alex >> On 7/22/2021 11:30 AM, Jan Lahoda wrote: >>> On Tue, 20 Jul 2021 13:35:24 GMT, Jim Laskey wrote: >>> >>>>> \u005C Unicode escape sequence not being treated as a backslash for general escape sequences. >>>> >>>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >>>> >>>> Remove comment duplicated by merge >>> >>> Looks good. >>> >>> ------------- >>> >>> Marked as reviewed by jlahoda (Reviewer). >>> >>> PR: https://git.openjdk.java.net/jdk17/pull/126 >>> From prappo at openjdk.java.net Fri Jul 23 13:28:25 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 23 Jul 2021 13:28:25 GMT Subject: RFR: 8271209: Fix doc comment typos in JavadocTokenizer Message-ID: 8271209: Fix doc comment typos in JavadocTokenizer ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/4889/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4889&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271209 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4889/head:pull/4889 PR: https://git.openjdk.java.net/jdk/pull/4889 From jlaskey at openjdk.java.net Fri Jul 23 13:28:26 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 23 Jul 2021 13:28:26 GMT Subject: RFR: 8271209: Fix doc comment typos in JavadocTokenizer In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 13:20:01 GMT, Pavel Rappo wrote: > 8271209: Fix doc comment typos in JavadocTokenizer LGTM ------------- Marked as reviewed by jlaskey (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4889 From jlaskey at openjdk.java.net Fri Jul 23 13:31:50 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 23 Jul 2021 13:31:50 GMT Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v8] In-Reply-To: References: Message-ID: > \u005C Unicode escape sequence not being treated as a backslash for general escape sequences. Jim Laskey 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 11 additional commits since the last revision: - Merge branch 'master' into 8269150 - Update UnicodeBackslash test to be easier to follow - Remove comment duplicated by merge - Merge branch 'master' into 8269150 - Merge branch '8269150b' into 8269150 - Use jdk15 logic - Proposed change - Merge branch 'master' into 8269150 - Updated the test to include all combinations - Merge branch 'master' into 8269150 - ... and 1 more: https://git.openjdk.java.net/jdk17/compare/68e5649b...3bc5789c ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/126/files - new: https://git.openjdk.java.net/jdk17/pull/126/files/cfc1614c..3bc5789c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=126&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=126&range=06-07 Stats: 1312 lines in 71 files changed: 921 ins; 224 del; 167 mod Patch: https://git.openjdk.java.net/jdk17/pull/126.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/126/head:pull/126 PR: https://git.openjdk.java.net/jdk17/pull/126 From prappo at openjdk.java.net Fri Jul 23 14:09:02 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 23 Jul 2021 14:09:02 GMT Subject: Integrated: 8271209: Fix doc comment typos in JavadocTokenizer In-Reply-To: References: Message-ID: <0PWKteK4pE3d9P2jL08aygr_bbgXhnQ3I318BaWA0jo=.9a2e8b4a-f86e-45ce-a2b0-ab9c778397a3@github.com> On Fri, 23 Jul 2021 13:20:01 GMT, Pavel Rappo wrote: > 8271209: Fix doc comment typos in JavadocTokenizer This pull request has now been integrated. Changeset: c9251db1 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/c9251db175803bb8d5e8b5b58ef34b50531c8e4b Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8271209: Fix doc comment typos in JavadocTokenizer Reviewed-by: jlaskey ------------- PR: https://git.openjdk.java.net/jdk/pull/4889 From jlaskey at openjdk.java.net Fri Jul 23 16:26:10 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 23 Jul 2021 16:26:10 GMT Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v4] In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 22:21:30 GMT, Joe Darcy wrote: >> Jim Laskey 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 four additional commits since the last revision: >> >> - Merge branch 'master' into 8269150 >> - Updated the test to include all combinations >> - Merge branch 'master' into 8269150 >> - Correct unicode escape handling in UnicodeReader, added test > > test/langtools/tools/javac/T8269150/T8269150.java line 31: > >> 29: */ >> 30: >> 31: public class T8269150 { > > Please, please, please give the test a meaningful name other than a bug id. (It is true javac tested used to follow that naming convention, but it has largely been abandoned.) Done > test/langtools/tools/javac/T8269150/T8269150.java line 33: > >> 31: public class T8269150 { >> 32: public static void main(String... args) { >> 33: String source = """ > > The test here would be clearer if written as a 2-D array of strings where the alternative forms of a particular sequence of characters were side-by-side on the same line. Done ------------- PR: https://git.openjdk.java.net/jdk17/pull/126 From jlaskey at openjdk.java.net Fri Jul 23 16:26:10 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 23 Jul 2021 16:26:10 GMT Subject: [jdk17] RFR: JDK-8269150 Unicode \u005C not treated as an escaping backslash [v8] In-Reply-To: References: Message-ID: On Wed, 23 Jun 2021 15:53:13 GMT, Jim Laskey wrote: >> test/langtools/tools/javac/T8269150/T8269150.java line 33: >> >>> 31: public class T8269150 { >>> 32: public static void main(String... args) { >>> 33: System.err.println("\u005C\\u005D"); >> >> This seems to be a very weak "don't crash" test. >> Shouldn't it check what is printed as well? > > Sure Test expanded ------------- PR: https://git.openjdk.java.net/jdk17/pull/126 From jjg at openjdk.java.net Fri Jul 23 18:07:04 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 23 Jul 2021 18:07:04 GMT Subject: RFR: 8266666: Implementation for snippets In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 14:13:16 GMT, Pavel Rappo wrote: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. The overall structure looks generally good. Nice work. That being said, I note the following ... * All new top-level classes should have a reasonable documention comment, including where appropriate the standard boilerplate (i.e. not on public API classes and interfaces) *

This is NOT part of any supported API. * If you write code that depends on this, you do so at your own risk. * This code and its internal interfaces are subject to change or * deletion without notice. * All new non-private methods should have a reasonable documentation comment * There's more than a typical number of chatty comments and/or fixme comments and/or code that needs to be uncommented. I'll do a separate review pass to note some of those examples. * Please work with @hns to determine the proposed CSS style(s) to be used, and not just the interim placeholder `sandybrown`. The color should be compatible with the existing color palette. Ideally, at the same time, in either this changes or a sibling changes, we should change the style of a default `

{code}` block to be similar with respect to the basic display characteristics.

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

Changes requested by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Fri Jul 23 18:51:07 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 23 Jul 2021 18:51:07 GMT
Subject: RFR: 8266666: Implementation for snippets
In-Reply-To: 
References: 
Message-ID: 

On Thu, 15 Jul 2021 14:13:16 GMT, Pavel Rappo  wrote:

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

More feedback;

1. It seems reasonable to introduce the `...taglets.snippets` package.  It seems excessive to have three sub packages within that, for `actions`, `parser` and `text`, especially when the last contains just a single class.

2. At some point soonish, we will need API somewhere to get the content of the snippet.  This is necessary to fulfill the goal in the JEP to support validation of snippet content. Without any such API, validation code would have to duplicate at least some of the code to handle snippets. This API should probably not be in `com.sun.source` and should probably be in the `jdk.javadoc` module, perhaps on the existing `StandardDoclet` class.  One way to do that would be to introduce a utility interface to provide access to support for taglets, and then have a method on `StandardDoclet` to access an instance of that utility for a specific snippet, identified by element and/or id.

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

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Fri Jul 23 20:17:02 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 23 Jul 2021 20:17:02 GMT
Subject: RFR: 8266666: Implementation for snippets
In-Reply-To: 
References: 
Message-ID: 

On Thu, 15 Jul 2021 14:13:16 GMT, Pavel Rappo  wrote:

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1147:

> 1145:     }
> 1146: 
> 1147:     // TODO: this method and seeTagToContent share much of the code; consider factoring common pieces out

Yes. the existing `seeTagToContent` handles all flavors of `@see` tag, and `{@link}`.

It ought to be possible to redirect the use of `@see  ` and `{@link}` to this method some some edited variant thereof.

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

PR: https://git.openjdk.java.net/jdk/pull/4795

From jjg at openjdk.java.net  Fri Jul 23 22:40:04 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 23 Jul 2021 22:40:04 GMT
Subject: RFR: 8266666: Implementation for snippets
In-Reply-To: 
References: 
Message-ID: 

On Thu, 15 Jul 2021 14:13:16 GMT, Pavel Rappo  wrote:

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 881:

> 879: .bold {
> 880:     font-weight: bold;
> 881: }

Both the name and definition seem very global.  Maybe it would be better to restrict the effect of these names to within `pre.snippet`. @hns to advise?

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

PR: https://git.openjdk.java.net/jdk/pull/4795

From duke at openjdk.java.net  Sat Jul 24 15:18:07 2021
From: duke at openjdk.java.net (duke)
Date: Sat, 24 Jul 2021 15:18:07 GMT
Subject: Withdrawn: 8266239: Some duplicated javac command-line options have
 repeated effect
In-Reply-To: 
References: 
Message-ID: 

On Fri, 28 May 2021 12:29:45 GMT, Guoxiong Li  wrote:

> Hi all,
> 
> Some duplicated info options (`--version`, `--help`, `--help-extra`, `--help-lint`, `--full-version`) have repeated effect. Please see the following example.
> 
> 
> $ javac -version -version
> javac 17-internal
> javac 17-internal
> 
> 
> The patch fixes it and adds a corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/4244

From yyang at openjdk.java.net  Mon Jul 26 02:26:28 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 26 Jul 2021 02:26:28 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack
Message-ID: 

Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash.

The attached test generates the following bytecode:

  void test();
    descriptor: ()V
    flags: (0x0000)
    Code:
      stack=2, locals=3, args_size=1
         0: iconst_1
         1: istore_1
         2: iload_1
         3: bipush        100
         5: if_icmpge     29
         8: iinc          1, 1
        11: goto          2
        14: astore_2
        15: iload_1
        16: bipush        100
        18: if_icmpge     27
        21: iinc          1, 1
        24: goto          15
        27: aload_2
        28: athrow
        29: return



Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug.

Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this:

  void test();
    descriptor: ()V
    flags: (0x0000)
    Code:
      stack=2, locals=3, args_size=1
         0: iconst_1
         1: istore_1
         2: nop
         3: iload_1
         4: bipush        100
         6: if_icmpge     30
         9: iinc          1, 1
        12: goto          3
        15: astore_2
        16: iload_1
        17: bipush        100
        19: if_icmpge     28
        22: iinc          1, 1
        25: goto          16
        28: aload_2
        29: athrow
        30: return
      Exception table:
         from    to  target type
             2     3    15   any


However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion.

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

Commit messages:
 - fix

Changes: https://git.openjdk.java.net/jdk/pull/4902/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4902&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271055
  Stats: 61 lines in 3 files changed: 59 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4902.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4902/head:pull/4902

PR: https://git.openjdk.java.net/jdk/pull/4902

From yyang at openjdk.java.net  Mon Jul 26 02:50:46 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 26 Jul 2021 02:50:46 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash.
> 
> The attached test generates the following bytecode:
> 
>   void test();
>     descriptor: ()V
>     flags: (0x0000)
>     Code:
>       stack=2, locals=3, args_size=1
>          0: iconst_1
>          1: istore_1
>          2: iload_1
>          3: bipush        100
>          5: if_icmpge     29
>          8: iinc          1, 1
>         11: goto          2
>         14: astore_2
>         15: iload_1
>         16: bipush        100
>         18: if_icmpge     27
>         21: iinc          1, 1
>         24: goto          15
>         27: aload_2
>         28: athrow
>         29: return
> 
> 
> 
> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug.
> 
> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this:
> 
>   void test();
>     descriptor: ()V
>     flags: (0x0000)
>     Code:
>       stack=2, locals=3, args_size=1
>          0: iconst_1
>          1: istore_1
>          2: nop
>          3: iload_1
>          4: bipush        100
>          6: if_icmpge     30
>          9: iinc          1, 1
>         12: goto          3
>         15: astore_2
>         16: iload_1
>         17: bipush        100
>         19: if_icmpge     28
>         22: iinc          1, 1
>         25: goto          16
>         28: aload_2
>         29: athrow
>         30: return
>       Exception table:
>          from    to  target type
>              2     3    15   any
> 
> 
> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion.

Yi Yang has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'JDK-8271055' of https://github.com/kelthuzadx/jdk into JDK-8271055
 - fix test
 - fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4902/files
  - new: https://git.openjdk.java.net/jdk/pull/4902/files/710d6d22..7b850f05

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4902&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4902&range=00-01

  Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4902.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4902/head:pull/4902

PR: https://git.openjdk.java.net/jdk/pull/4902

From thartmann at openjdk.java.net  Mon Jul 26 07:03:06 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Jul 2021 07:03:06 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 Jul 2021 02:50:46 GMT, Yi Yang  wrote:

>> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash.
>> 
>> The attached test generates the following bytecode:
>> 
>>   void test();
>>     descriptor: ()V
>>     flags: (0x0000)
>>     Code:
>>       stack=2, locals=3, args_size=1
>>          0: iconst_1
>>          1: istore_1
>>          2: iload_1
>>          3: bipush        100
>>          5: if_icmpge     29
>>          8: iinc          1, 1
>>         11: goto          2
>>         14: astore_2
>>         15: iload_1
>>         16: bipush        100
>>         18: if_icmpge     27
>>         21: iinc          1, 1
>>         24: goto          15
>>         27: aload_2
>>         28: athrow
>>         29: return
>> 
>> 
>> 
>> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug.
>> 
>> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this:
>> 
>>   void test();
>>     descriptor: ()V
>>     flags: (0x0000)
>>     Code:
>>       stack=2, locals=3, args_size=1
>>          0: iconst_1
>>          1: istore_1
>>          2: nop
>>          3: iload_1
>>          4: bipush        100
>>          6: if_icmpge     30
>>          9: iinc          1, 1
>>         12: goto          3
>>         15: astore_2
>>         16: iload_1
>>         17: bipush        100
>>         19: if_icmpge     28
>>         22: iinc          1, 1
>>         25: goto          16
>>         28: aload_2
>>         29: athrow
>>         30: return
>>       Exception table:
>>          from    to  target type
>>              2     3    15   any
>> 
>> 
>> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion.
>
> Yi Yang has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge branch 'JDK-8271055' of https://github.com/kelthuzadx/jdk into JDK-8271055
>  - fix test
>  - fix

Just wondering, did you sync up with @chhagedorn who (still) has this assigned? Not sure if he already started working on it.

src/hotspot/share/runtime/deoptimization.cpp line 787:

> 785:           if (!Bytecodes::is_invoke(cur_code) && cur_code != Bytecodes::_athrow) {
> 786:             // Get expression stack size for the next bytecode
> 787:             if(UseNewCode) {

I assume you intended to remove this from the final version of the patch.

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

PR: https://git.openjdk.java.net/jdk/pull/4902

From yyang at openjdk.java.net  Mon Jul 26 07:14:09 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 26 Jul 2021 07:14:09 GMT
Subject: Withdrawn: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack
In-Reply-To: 
References: 
Message-ID: 

On Mon, 26 Jul 2021 02:10:18 GMT, Yi Yang  wrote:

> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash.
> 
> The attached test generates the following bytecode:
> 
>   void test();
>     descriptor: ()V
>     flags: (0x0000)
>     Code:
>       stack=2, locals=3, args_size=1
>          0: iconst_1
>          1: istore_1
>          2: iload_1
>          3: bipush        100
>          5: if_icmpge     29
>          8: iinc          1, 1
>         11: goto          2
>         14: astore_2
>         15: iload_1
>         16: bipush        100
>         18: if_icmpge     27
>         21: iinc          1, 1
>         24: goto          15
>         27: aload_2
>         28: athrow
>         29: return
> 
> 
> 
> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug.
> 
> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this:
> 
>   void test();
>     descriptor: ()V
>     flags: (0x0000)
>     Code:
>       stack=2, locals=3, args_size=1
>          0: iconst_1
>          1: istore_1
>          2: nop
>          3: iload_1
>          4: bipush        100
>          6: if_icmpge     30
>          9: iinc          1, 1
>         12: goto          3
>         15: astore_2
>         16: iload_1
>         17: bipush        100
>         19: if_icmpge     28
>         22: iinc          1, 1
>         25: goto          16
>         28: aload_2
>         29: athrow
>         30: return
>       Exception table:
>          from    to  target type
>              2     3    15   any
> 
> 
> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/4902

From yyang at openjdk.java.net  Mon Jul 26 07:14:08 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 26 Jul 2021 07:14:08 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 26 Jul 2021 06:56:02 GMT, Tobias Hartmann  wrote:

>> Yi Yang has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8271055' of https://github.com/kelthuzadx/jdk into JDK-8271055
>>  - fix test
>>  - fix
>
> src/hotspot/share/runtime/deoptimization.cpp line 787:
> 
>> 785:           if (!Bytecodes::is_invoke(cur_code) && cur_code != Bytecodes::_athrow) {
>> 786:             // Get expression stack size for the next bytecode
>> 787:             if(UseNewCode) {
> 
> I assume you intended to remove this from the final version of the patch.

Sorry... I haven't sync up with @chhagedorn, I picked up a starter issue to work on it and missed assignee. I will update my query condition to filter unassigned issue later.

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

PR: https://git.openjdk.java.net/jdk/pull/4902

From chagedorn at openjdk.java.net  Mon Jul 26 07:21:10 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 26 Jul 2021 07:21:10 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 Jul 2021 02:50:46 GMT, Yi Yang  wrote:

>> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash.
>> 
>> The attached test generates the following bytecode:
>> 
>>   void test();
>>     descriptor: ()V
>>     flags: (0x0000)
>>     Code:
>>       stack=2, locals=3, args_size=1
>>          0: iconst_1
>>          1: istore_1
>>          2: iload_1
>>          3: bipush        100
>>          5: if_icmpge     29
>>          8: iinc          1, 1
>>         11: goto          2
>>         14: astore_2
>>         15: iload_1
>>         16: bipush        100
>>         18: if_icmpge     27
>>         21: iinc          1, 1
>>         24: goto          15
>>         27: aload_2
>>         28: athrow
>>         29: return
>> 
>> 
>> 
>> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug.
>> 
>> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this:
>> 
>>   void test();
>>     descriptor: ()V
>>     flags: (0x0000)
>>     Code:
>>       stack=2, locals=3, args_size=1
>>          0: iconst_1
>>          1: istore_1
>>          2: nop
>>          3: iload_1
>>          4: bipush        100
>>          6: if_icmpge     30
>>          9: iinc          1, 1
>>         12: goto          3
>>         15: astore_2
>>         16: iload_1
>>         17: bipush        100
>>         19: if_icmpge     28
>>         22: iinc          1, 1
>>         25: goto          16
>>         28: aload_2
>>         29: athrow
>>         30: return
>>       Exception table:
>>          from    to  target type
>>              2     3    15   any
>> 
>> 
>> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion.
>
> Yi Yang has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge branch 'JDK-8271055' of https://github.com/kelthuzadx/jdk into JDK-8271055
>  - fix test
>  - fix

Hi @kelthuzadx, please make sure to always have a JBS issue assigned to you before creating a PR for it. If the issue is already assigned you can do a sync with the assignee and ask to take it over.

In this case, I have not started working on it, yet, so you can take it over and reopen the PR again.

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

PR: https://git.openjdk.java.net/jdk/pull/4902

From yyang at openjdk.java.net  Mon Jul 26 07:30:12 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 26 Jul 2021 07:30:12 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 26 Jul 2021 07:17:37 GMT, Christian Hagedorn  wrote:

>> Yi Yang has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8271055' of https://github.com/kelthuzadx/jdk into JDK-8271055
>>  - fix test
>>  - fix
>
> Hi @kelthuzadx, please make sure to always have a JBS issue assigned to you before creating a PR for it. If the issue is already assigned you can do a sync with the assignee and ask to take it over.
> 
> In this case, I have not started working on it, yet, so you can take it over and reopen the PR again.

Thank you @chhagedorn! I will take care of this later.

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

PR: https://git.openjdk.java.net/jdk/pull/4902

From yyang at openjdk.java.net  Mon Jul 26 07:43:39 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 26 Jul 2021 07:43:39 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash.
> 
> The attached test generates the following bytecode:
> 
>   void test();
>     descriptor: ()V
>     flags: (0x0000)
>     Code:
>       stack=2, locals=3, args_size=1
>          0: iconst_1
>          1: istore_1
>          2: iload_1
>          3: bipush        100
>          5: if_icmpge     29
>          8: iinc          1, 1
>         11: goto          2
>         14: astore_2
>         15: iload_1
>         16: bipush        100
>         18: if_icmpge     27
>         21: iinc          1, 1
>         24: goto          15
>         27: aload_2
>         28: athrow
>         29: return
> 
> 
> 
> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug.
> 
> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this:
> 
>   void test();
>     descriptor: ()V
>     flags: (0x0000)
>     Code:
>       stack=2, locals=3, args_size=1
>          0: iconst_1
>          1: istore_1
>          2: nop
>          3: iload_1
>          4: bipush        100
>          6: if_icmpge     30
>          9: iinc          1, 1
>         12: goto          3
>         15: astore_2
>         16: iload_1
>         17: bipush        100
>         19: if_icmpge     28
>         22: iinc          1, 1
>         25: goto          16
>         28: aload_2
>         29: athrow
>         30: return
>       Exception table:
>          from    to  target type
>              2     3    15   any
> 
> 
> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  remove usenewcode

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4902/files
  - new: https://git.openjdk.java.net/jdk/pull/4902/files/7b850f05..97dc5de2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4902&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4902&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4902.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4902/head:pull/4902

PR: https://git.openjdk.java.net/jdk/pull/4902

From prappo at openjdk.java.net  Mon Jul 26 12:09:03 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 26 Jul 2021 12:09:03 GMT
Subject: RFR: 8266666: Implementation for snippets
In-Reply-To: 
References: 
Message-ID: 

On Thu, 15 Jul 2021 14:13:16 GMT, Pavel Rappo  wrote:

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

>
> * All new top-level classes should have a reasonable documention comment, including where appropriate the standard boilerplate (i.e. not on public API classes and interfaces)
>   *  
This is NOT part of any supported API.
>   *  If you write code that depends on this, you do so at your own risk.
>   *  This code and its internal interfaces are subject to change or
>   *  deletion without notice.
> * All new non-private methods should have a reasonable documentation comment
>

I'm ok with adding the boilerplate "This is NOT part of any supported API" note, as well as adding method comments where practical. However, I note that this PR comprises mostly an internal implementation and not a public API. Internal implementation comments are more like documentation rather than specification. Such documentation is virtually never built and is read in an IDE while eyeballing the respective code and tests. I think it's overkill and waste of resources to use doc comments in such a case.

>
> * There's more than a typical number of chatty comments and/or fixme comments and/or code that needs to be uncommented.   I'll do a separate review pass to note some of those examples.
>

I'm currently working on removing as many FIXMEs and TODOs as possible. I think of a FIXME comment as a "review breakpoint" that highlights an issue that has to be resolved before the code is accepted. 

I would be interested to learn which comments you consider "chatty". I look forward to fixing them with your help. One note, though. For an internal implementation, I try hard to make only the "why" comments, not the "what" comments. "What" comments have their place, but they should be sparing and reserved for non-trivial domains. For trivial domains, the "what" should be obvious. If it is not, I failed at coding, not at commenting.

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

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Mon Jul 26 12:59:12 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 26 Jul 2021 12:59:12 GMT
Subject: RFR: 8266666: Implementation for snippets
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 23 Jul 2021 18:48:27 GMT, Jonathan Gibbons  wrote:

> More feedback;
> 
> 1. It seems reasonable to introduce the `...taglets.snippets` package.  It seems excessive to have three sub packages within that, for `actions`, `parser` and `text`, especially when the last contains just a single class.

That package structure was initially there to keep the dependencies clear. That said, I'm okay with squashing it into a single package for practical reasons.

> 2. At some point soonish, we will need API somewhere to get the content of the snippet.  This is necessary to fulfill the goal in the JEP to support validation of snippet content. Without any such API, validation code would have to duplicate at least some of the code to handle snippets. This API should probably not be in `com.sun.source` and should probably be in the `jdk.javadoc` module, perhaps on the existing `StandardDoclet` class.  One way to do that would be to introduce a utility interface to provide access to support for taglets, and then have a method on `StandardDoclet` to access an instance of that utility for a specific snippet, identified by element and/or id.

We can discuss that API either in this PR or in a separate thread on javadoc-dev at openjdk.java.net. (Separately: is this @/at trick still efficient? Modern email-address harvesting is surely smarter than that.)

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

PR: https://git.openjdk.java.net/jdk/pull/4795

From yyang at openjdk.java.net  Mon Jul 26 14:58:13 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 26 Jul 2021 14:58:13 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 Jul 2021 07:43:39 GMT, Yi Yang  wrote:

>> Hi, I'm trying to fix JDK-8271055. The root cause is that some basic blocks are not interpreted because there is no trap bytecode inside them, these basic blocks eventually become unreachable and lead to a crash. Maybe we need to coordinate compiler and hotspot groups to fix this crash.
>> 
>> ----
>> 
>> The attached test generates the following bytecode:
>> 
>>   void test();
>>     descriptor: ()V
>>     flags: (0x0000)
>>     Code:
>>       stack=2, locals=3, args_size=1
>>          0: iconst_1
>>          1: istore_1
>>          2: iload_1
>>          3: bipush        100
>>          5: if_icmpge     29
>>          8: iinc          1, 1
>>         11: goto          2
>>         14: astore_2
>>         15: iload_1
>>         16: bipush        100
>>         18: if_icmpge     27
>>         21: iinc          1, 1
>>         24: goto          15
>>         27: aload_2
>>         28: athrow
>>         29: return
>> 
>> 
>> 
>> Javac generates some unreachable basic blocks(BCI 14 - 28), and there is no exception table for them, VM knows nothing about them. I found the same bug report at JDK-8022186 which was marked as `Fixed`, but I think it was not properly fixed, In some similar cases, javac cannot work well, I have filed https://bugs.openjdk.java.net/browse/JDK-8271254 for another javac bug.
>> 
>> Going back to this bug, the proposed change is to insert a nop in empty try-block so that javac can generate the correct exception table. Now generated bytecodes look like this:
>> 
>>   void test();
>>     descriptor: ()V
>>     flags: (0x0000)
>>     Code:
>>       stack=2, locals=3, args_size=1
>>          0: iconst_1
>>          1: istore_1
>>          2: nop
>>          3: iload_1
>>          4: bipush        100
>>          6: if_icmpge     30
>>          9: iinc          1, 1
>>         12: goto          3
>>         15: astore_2
>>         16: iload_1
>>         17: bipush        100
>>         19: if_icmpge     28
>>         22: iinc          1, 1
>>         25: goto          16
>>         28: aload_2
>>         29: athrow
>>         30: return
>>       Exception table:
>>          from    to  target type
>>              2     3    15   any
>> 
>> 
>> However, this is not the end. Even if the exception table is correctly generated, VM only enters GenerateOopMap::do_exception_edge when the bytecode may be trapped. In order to setup handler block, we need to relax this restriction to allow even bytecodes such as nop to correctly enter GenerateOopMap::do_exception_edge. Otherwise, handler block will not be interpreted, its stack is problematic and finally hits the assertion.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove usenewcode

P.S. In summary, I think there are two bugs: one for javac, one for VM.

-- Javac side:
The proposed fix is to insert a "nop".

I'm not good at this area, hope to have more experts' comments.

--- VM side:
To verify what I said, we can consider the below case which does not contain trap bytecodes in some unreachable basic blocks:


public class VerifyStackWithUnreachableBlock {
    public static void main(String[] strArr) {
        VerifyStackWithUnreachableBlock _instance = new VerifyStackWithUnreachableBlock();
        for (int i = 0; i < 10000; i++) {
            _instance.test();
        }
    }

    void test() {
        int i8 = 1;
        try {
            int p=0;
            p++;
        } finally {
            for (; i8 < 100; i8++) {
            }
        }
    }
}


It crashes with the same assertion:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/qingfeng.yy/jdktip/src/hotspot/share/oops/generateOopMap.cpp:2220), pid=130592, tid=130631
#  assert(bb->is_reachable()) failed: getting result from unreachable basicblock
#
# JRE version: OpenJDK Runtime Environment (18.0) (slowdebug build 18-internal+0-adhoc.qingfengyy.jdktip)
# Java VM: OpenJDK 64-Bit Server VM (slowdebug 18-internal+0-adhoc.qingfengyy.jdktip, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xa505b1]  GenerateOopMap::result_for_basicblock(int)+0xb5
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/qingfeng.yy/jdktip/build/linux-x86_64-server-slowdebug/images/jdk -Dcompile.jdk=/home/qingfeng.yy/jdktip/build/linux-x86_64-server-slowdebug/images/jdk -Dtest.timeout.factor=1.0 -Dtest.root=/home/qingfeng.yy/jdktip/test/hotspot/jtreg -Dtest.name=compiler/interpreter/VerifyStackWithUnreachableBlock.java -Dtest.file=/home/qingfeng.yy/jdktip/test/hotspot/jtreg/compiler/interpreter/VerifyStackWithUnreachableBlock.java -Dtest.src=/home/qingfeng.yy/jdktip/test/hotspot/jtreg/compiler/interpreter -Dtest.src.path=/home/qingfeng.yy/jdktip/test/hotspot/jtreg/compiler/interpreter -Dtest.classes=/home/qingfeng.yy/jdktip/JTwork/classes/0/compiler/interpreter/VerifyStackWithUnreachableBlock.d -Dtest.class.path=/home/qingfeng.yy/jdktip/JTwork/classes/0/compiler/interpreter/VerifyStackWithUnreachableBlock.d -XX:+IgnoreUnrecognizedVMOptions -XX:+VerifyStack com.sun.javatest.regtest.agent.MainWra
 pper /home/qingfeng.yy/jdktip/JTwork/compiler/interpreter/VerifyStackWithUnreachableBlock.d/main.0.jta

Host: e69e13043.et15sqa, Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz, 96 cores, 503G, Alibaba Group Enterprise Linux Server release 7.2 (Paladin)
Time: Mon Jul 26 22:46:38 2021 CST elapsed time: 1.894403 seconds (0d 0h 0m 1s)

---------------  T H R E A D  ---------------

Current thread (0x00007f415c3a5ab0):  JavaThread "MainThread" [_thread_in_Java, id=130631, stack(0x00007f40cd9bc000,0x00007f40cdabd000)]

Stack: [0x00007f40cd9bc000,0x00007f40cdabd000],  sp=0x00007f40cdab8c50,  free space=1011k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xa505b1]  GenerateOopMap::result_for_basicblock(int)+0xb5
V  [libjvm.so+0xfa41b3]  OopMapForCacheEntry::compute_map(Thread*)+0x155
V  [libjvm.so+0xfa4d23]  OopMapCacheEntry::fill(methodHandle const&, int)+0xdd
V  [libjvm.so+0xfa5b4b]  OopMapCache::compute_one_oop_map(methodHandle const&, int, InterpreterOopMap*)+0x4d
V  [libjvm.so+0x83ef0e]  Deoptimization::unpack_frames(JavaThread*, int)+0x642
v  ~DeoptimizationBlob
....

After applying this patch, it works.

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

PR: https://git.openjdk.java.net/jdk/pull/4902

From hannesw at openjdk.java.net  Mon Jul 26 17:18:36 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 26 Jul 2021 17:18:36 GMT
Subject: RFR: 8266666: Implementation for snippets
In-Reply-To: 
References: 
Message-ID: 

On Thu, 15 Jul 2021 14:13:16 GMT, Pavel Rappo  wrote:

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Overall the code looks good! 

A few comments inline. I'll have a look at the stylesheet changes next.

src/jdk.compiler/share/classes/com/sun/source/doctree/SnippetTree.java line 46:

> 44:  *
> 45: * > 46: * @since 17 Should be `@since 18` (a few other instances) src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java line 108: > 106: } > 107: > 108: String r = null; I would prefer if variables such as this that are used farther than a few lines from their definition had more meaningful names. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/parser/Parser.java line 275: > 273: throw new ParseException("Unexpected attributes", t.lineSourceOffset + t.markupLineOffset + t.nameLineOffset); > 274: } > 275: actions.add(new Bookmark(region.value(), text.subText(t.start(), t.end() - 1))); This method is a bit hard on the eyes and runs quite wide. Maybe add a few more line breaks on those very long lines? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/text/AnnotatedText.java line 46: > 44: * rich text style. > 45: */ > 46: public class AnnotatedText { As far as I can see, this class is always parameterized with Style. Do you foresee any other types of annotations being used with it? ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From hannesw at openjdk.java.net Mon Jul 26 17:18:37 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 26 Jul 2021 17:18:37 GMT Subject: RFR: 8266666: Implementation for snippets In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 22:35:38 GMT, Jonathan Gibbons wrote: >> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 881: > >> 879: .bold { >> 880: font-weight: bold; >> 881: } > > Both the name and definition seem very global. Maybe it would be better to restrict the effect of these names to within `pre.snippet`. @hns to advise? I would also limit these to within `pre.snippet`, i.e: pre.snippet .italic { ... } ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From darcy at openjdk.java.net Mon Jul 26 17:25:38 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 26 Jul 2021 17:25:38 GMT Subject: [jdk17] RFR: JDK-8269150 UnicodeReader not translating \u005c\\u005d to \\] [v8] In-Reply-To: References: Message-ID: <5JqhSGAEZMmgKKLtwvK23jgBXebXwAM3LiWbqHJXs_4=.19a349af-fe5b-47c8-815b-9170574ae3a1@github.com> On Fri, 23 Jul 2021 13:31:50 GMT, Jim Laskey wrote: >> This issue relates to *Unicode escapes*, described in section 3.3 of the JLS. javac interprets Unicode escapes during the reading of ASCII characters from source. Later on, javac interprets *escape sequences*, described in section 3.7 of the JLS, during the tokenization of character literals, string literals, and text blocks. Escape sequences are only indirectly affected by this bug. >> >> During reading, a _normal backslash_ (that is, the ASCII `` character, not the corresponding Unicode escape `\u005c`) followed by another normal backslash is treated collectively as a pair of backslash characters. No further interpretation is done. This means that if a normal backslash immediately precedes the sequence `` `u` `A` `B` `C` `D` which would "normally" be interpreted as an Unicode escape, then the interpretation of that sequence as a Unicode escape is suppressed. >> >> For example, the sequence `\u2022` would be interpreted as the `?` character, whereas `\\u2022` would be interpreted as the seven characters `` `` `u` `2` `0` `2` `2`. >> >> An issue arises when Java developers choose to use a _Unicode escape backslash_ `\u005c` in their source code, instead of a normal backslash. Prior to JDK 16, if the Unicode escape backslash was followed by a second Unicode escape, then *the second Unicode escape was always interpreted*. The normal backslash at the beginning of the second Unicode escape (immediately followed by `u`) was *not* paired with the preceding Unicode escape backslash. Elsewise, any following normal backslash will be paired with the `\u005c`. >> >> For example, the sequence `\u005c\u2022` would be interpreted as `` and `?`, whereas `\u005c\tXYZ` would be interpreted as `` `` `t` `X` `Y` `Z`. >> >> The bug in JDK 16 ignored `\u005c` as having any effect on Unicode interpretation. Using the example from compiler-dev discussions, `\u005c\\u005d` : >> >> - Prior to JDK 16, it was interpreted as `` `` `]` >> - JDK 16 interpreted it as `` `` `` `u` `0` `0` `5` `d` which would produce a syntax error downstream in the lexer because the escape sequence `\u` is invalid. > > Jim Laskey 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 11 additional commits since the last revision: > > - Merge branch 'master' into 8269150 > - Update UnicodeBackslash test to be easier to follow > - Remove comment duplicated by merge > - Merge branch 'master' into 8269150 > - Merge branch '8269150b' into 8269150 > - Use jdk15 logic > - Proposed change > - Merge branch 'master' into 8269150 > - Updated the test to include all combinations > - Merge branch 'master' into 8269150 > - ... and 1 more: https://git.openjdk.java.net/jdk17/compare/3e29056e...3bc5789c Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/126 From jlaskey at openjdk.java.net Mon Jul 26 18:07:46 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 26 Jul 2021 18:07:46 GMT Subject: [jdk17] Integrated: JDK-8269150 UnicodeReader not translating \u005c\\u005d to \\] In-Reply-To: References: Message-ID: On Wed, 23 Jun 2021 15:30:25 GMT, Jim Laskey wrote: > This issue relates to *Unicode escapes*, described in section 3.3 of the JLS. javac interprets Unicode escapes during the reading of ASCII characters from source. Later on, javac interprets *escape sequences*, described in section 3.7 of the JLS, during the tokenization of character literals, string literals, and text blocks. Escape sequences are only indirectly affected by this bug. > > During reading, a _normal backslash_ (that is, the ASCII `` character, not the corresponding Unicode escape `\u005c`) followed by another normal backslash is treated collectively as a pair of backslash characters. No further interpretation is done. This means that if a normal backslash immediately precedes the sequence `` `u` `A` `B` `C` `D` which would "normally" be interpreted as an Unicode escape, then the interpretation of that sequence as a Unicode escape is suppressed. > > For example, the sequence `\u2022` would be interpreted as the `?` character, whereas `\\u2022` would be interpreted as the seven characters `` `` `u` `2` `0` `2` `2`. > > An issue arises when Java developers choose to use a _Unicode escape backslash_ `\u005c` in their source code, instead of a normal backslash. Prior to JDK 16, if the Unicode escape backslash was followed by a second Unicode escape, then *the second Unicode escape was always interpreted*. The normal backslash at the beginning of the second Unicode escape (immediately followed by `u`) was *not* paired with the preceding Unicode escape backslash. Elsewise, any following normal backslash will be paired with the `\u005c`. > > For example, the sequence `\u005c\u2022` would be interpreted as `` and `?`, whereas `\u005c\tXYZ` would be interpreted as `` `` `t` `X` `Y` `Z`. > > The bug in JDK 16 ignored `\u005c` as having any effect on Unicode interpretation. Using the example from compiler-dev discussions, `\u005c\\u005d` : > > - Prior to JDK 16, it was interpreted as `` `` `]` > - JDK 16 interpreted it as `` `` `` `u` `0` `0` `5` `d` which would produce a syntax error downstream in the lexer because the escape sequence `\u` is invalid. This pull request has now been integrated. Changeset: b76a8388 Author: Jim Laskey URL: https://git.openjdk.java.net/jdk17/commit/b76a83888b00faff602726f5409e1c902b91e908 Stats: 96 lines in 2 files changed: 88 ins; 4 del; 4 mod 8269150: UnicodeReader not translating \u005c\\u005d to \\] Reviewed-by: jjg, jlahoda, darcy ------------- PR: https://git.openjdk.java.net/jdk17/pull/126 From jwilhelm at openjdk.java.net Tue Jul 27 00:10:16 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 27 Jul 2021 00:10:16 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8269150: UnicodeReader not translating \u005c\\u005d to \\] - 8271175: runtime/jni/FindClassUtf8/FindClassUtf8.java doesn't have to be run in othervm - 8271222: two runtime/Monitor tests don't check exit code - 8015886: java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.java sometimes failed on ubuntu The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4907&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4907&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4907/files Stats: 118 lines in 6 files changed: 103 ins; 4 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/4907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4907/head:pull/4907 PR: https://git.openjdk.java.net/jdk/pull/4907 From jwilhelm at openjdk.java.net Tue Jul 27 01:01:43 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 27 Jul 2021 01:01:43 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: <-OT6zWAEV5o2OgQis1sjbtEDQD35nUYjxdaevupzDsg=.31df5a31-e2ba-4d9c-a682-275625c83bec@github.com> On Tue, 27 Jul 2021 00:00:03 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: eb6da888 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/eb6da88817f7bc903a51130271c9a5de928c603d Stats: 118 lines in 6 files changed: 103 ins; 4 del; 11 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4907 From prappo at openjdk.java.net Tue Jul 27 11:06:35 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 27 Jul 2021 11:06:35 GMT Subject: RFR: 8266666: Implementation for snippets [v2] In-Reply-To: References: Message-ID: <9OipP1n1ARh_8F7vFRLwRt5axgIvCAhIrkAtOV1Fh5g=.ad3c1991-0f24-4423-8823-f4bba622f231@github.com> > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Update @since tags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/dd172b50..c4e5b79c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=00-01 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From adam.sotona at oracle.com Tue Jul 27 12:29:58 2021 From: adam.sotona at oracle.com (Adam Sotona) Date: Tue, 27 Jul 2021 12:29:58 +0000 Subject: 8268869: java in source-file mode suggests javac-only Xlint flags Message-ID: <75874C9B-FD3A-4F83-A70E-72573B454392@oracle.com> Please review. Thank you, Adam ?On 28.06.2021 15:48, "compiler-dev on behalf of Adam Sotona" wrote: java in source-file mode (see JEP 330) displays compiler notes suggesting recompile with -Xlint:deprecation and -Xlint:unchecked. According JEP 330 these advanced javac optionns are not allowed. The goal with JEP 330 was to support developers that are at the early stages of learning Java, so options such as -Xlint are out of their scope. This patch prevents displaying "Note: Recompile with -Xlint:deprecation for details." and "Note: Recompile with -Xlint:unchecked for details." by implicitly enabling -Xlint:deprecation and -Xlint:unchecked in com.sun.tool.javac.launcher.Main for all invocations. Beside avoiding prohibited javac option suggestion notes this patch has positive effect of more verbose compilation diagnostic. Higher diagnostic verbosity is appreciated by users learning Java on single-source programs in java source-file mode. Similar case with -Xdiags:verbose was reported in JDK-8248843 and resolved in commit openjdk/jdk/31d0f0d8after review openjdk/jdk/4094 The patch also provides new test "testNoRecompileWithSuggestions" detecting unwanted recompilation suggestions in java in source-file mode execution. The test cover also case from JDK-8248843 with -Xdiags:verbose ------------- Commit messages: - 8268869: java in source-file mode suggests javac-only Xlint flags Changes: https://git.openjdk.java.net/jdk/pull/4613/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4613&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268869 Stats: 35 lines in 2 files changed: 33 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4613.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4613/head:pull/4613 PR: https://git.openjdk.java.net/jdk/pull/4613 From prappo at openjdk.java.net Tue Jul 27 15:41:38 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 27 Jul 2021 15:41:38 GMT Subject: RFR: 8266666: Implementation for snippets [v2] In-Reply-To: <9OipP1n1ARh_8F7vFRLwRt5axgIvCAhIrkAtOV1Fh5g=.ad3c1991-0f24-4423-8823-f4bba622f231@github.com> References: <9OipP1n1ARh_8F7vFRLwRt5axgIvCAhIrkAtOV1Fh5g=.ad3c1991-0f24-4423-8823-f4bba622f231@github.com> Message-ID: On Tue, 27 Jul 2021 11:06:35 GMT, Pavel Rappo wrote: >> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Update @since tags > _Mailing list message from [Jonathan Gibbons](mailto:jonathan.gibbons at oracle.com) on [javadoc-dev](mailto:javadoc-dev at mail.openjdk.java.net):_ > > The comments don't need to be of core-libs quality, but at least some of > the problems we have had in the code of late has been discerning the > original intent, so at least some amount of comment/documentation is > useful, even if we don't run it through javadoc or even doclint. > > Think of the comments as "pay it forward" to our future selves. > > -- Jon > > On 7/26/21 5:09 AM, Pavel Rappo wrote: > > > I'm ok with adding the boilerplate "This is NOT part of any supported API" note, as well as adding method comments where practical. However, I note that this PR comprises mostly an internal implementation and not a public API. Internal implementation comments are more like documentation rather than specification. Such documentation is virtually never built and is read in an IDE while eyeballing the respective code and tests. I think it's overkill and waste of resources to use doc comments in such a case. Project conventions are more important than my preferences. Although I don't see much value in such comments, I added some in commit 4300903. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Tue Jul 27 15:41:37 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 27 Jul 2021 15:41:37 GMT Subject: RFR: 8266666: Implementation for snippets [v3] In-Reply-To: References: Message-ID: <7jH92hVRRH6HDBYOL8uQ3d9Cf0XD8fiVDcsk6yGaNhI=.18858434-b340-4816-a726-eb72a52d5038@github.com> > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Improve comments This commit adds trivial commentary to some of the Java declarations. This commit also adds the "This is NOT part of any supported API..." disclaimer. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/c4e5b79c..43009031 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=01-02 Stats: 145 lines in 12 files changed: 139 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Tue Jul 27 16:01:32 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 27 Jul 2021 16:01:32 GMT Subject: RFR: 8266666: Implementation for snippets [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jul 2021 17:05:45 GMT, Hannes Walln?fer wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve comments >> >> This commit adds trivial commentary to some of the Java declarations. This commit also adds the "This is NOT part of any supported API..." disclaimer. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/parser/Parser.java line 275: > >> 273: throw new ParseException("Unexpected attributes", t.lineSourceOffset + t.markupLineOffset + t.nameLineOffset); >> 274: } >> 275: actions.add(new Bookmark(region.value(), text.subText(t.start(), t.end() - 1))); > > This method is a bit hard on the eyes and runs quite wide. Maybe add a few more line breaks on those very long lines? So just to be clear, Hannes. Do you suggest to structure the rules like this? pre.snippet { background-color: #e8e8e8; padding: 10px; margin: 12px 0; overflow: auto; white-space: pre; } pre.snippet .italic { font-style: italic; } pre.snippet .bold { font-weight: bold; } pre.snippet .highlighted { background-color: sandybrown; border-radius: 10%; } ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From hannesw at openjdk.java.net Tue Jul 27 18:36:34 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 27 Jul 2021 18:36:34 GMT Subject: RFR: 8266666: Implementation for snippets [v3] In-Reply-To: References: Message-ID: <8EDas7e5sRHL5j5yERTW77gAMhFmc0lNRERJwCSfQzU=.06e401b9-ca6c-4b37-98e7-0ac2e9bdbae1@github.com> On Tue, 27 Jul 2021 15:59:00 GMT, Pavel Rappo wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/parser/Parser.java line 275: >> >>> 273: throw new ParseException("Unexpected attributes", t.lineSourceOffset + t.markupLineOffset + t.nameLineOffset); >>> 274: } >>> 275: actions.add(new Bookmark(region.value(), text.subText(t.start(), t.end() - 1))); >> >> This method is a bit hard on the eyes and runs quite wide. Maybe add a few more line breaks on those very long lines? > > So just to be clear, Hannes. Do you suggest to structure the rules like this? > > > pre.snippet { > background-color: #e8e8e8; > padding: 10px; > margin: 12px 0; > overflow: auto; > white-space: pre; > } > > pre.snippet .italic { > font-style: italic; > } > > pre.snippet .bold { > font-weight: bold; > } > > pre.snippet .highlighted { > background-color: sandybrown; > border-radius: 10%; > } Yes, that's what I would propose. It limits the definitions to contents of `
` elements. Another idea would have been to use snippet-specific class names such as `.snippet-italic`, but that's more verbose and less elegant.

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

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Tue Jul 27 19:17:35 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 27 Jul 2021 19:17:35 GMT
Subject: RFR: 8266666: Implementation for snippets [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 26 Jul 2021 15:25:03 GMT, Hannes Walln?fer  wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 881:
>> 
>>> 879: .bold {
>>> 880:     font-weight: bold;
>>> 881: }
>> 
>> Both the name and definition seem very global.  Maybe it would be better to restrict the effect of these names to within `pre.snippet`. @hns to advise?
>
> I would also limit these to within `pre.snippet`, i.e: 
> 
>     pre.snippet .italic {
>         ...
>     }

In commit 34b274c, I changed the CSS as suggested.

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

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Tue Jul 27 19:17:34 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 27 Jul 2021 19:17:34 GMT
Subject: RFR: 8266666: Implementation for snippets [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Make CSS rules more specific

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4795/files
  - new: https://git.openjdk.java.net/jdk/pull/4795/files/43009031..34b274cb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795

PR: https://git.openjdk.java.net/jdk/pull/4795

From prappo at openjdk.java.net  Wed Jul 28 14:40:57 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 28 Jul 2021 14:40:57 GMT
Subject: RFR: 8266666: Implementation for snippets [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 Jul 2021 12:55:17 GMT, Hannes Walln?fer  wrote:

>> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Change AnnotatedText to StyledText
>>    
>>    Renames the class, removes its generic parameter, and changes the related terminology from "annotate" to "style".
>>  - Restructure ...toolkit.taglets.snippet.** packages
>>    
>>    This commit moves the contents of the jdk.javadoc.internal.doclets.toolkit.taglets.snippet.{action,parser,text} packages into the jdk.javadoc.internal.doclets.toolkit.taglets.snippet package.
>
> src/jdk.compiler/share/classes/com/sun/source/doctree/SnippetTree.java line 46:
> 
>> 44:  *
>> 45: * >> 46: * @since 17 > > Should be `@since 18` (a few other instances) Fixed in commit c4e5b79. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/text/AnnotatedText.java line 46: > >> 44: * rich text style. >> 45: */ >> 46: public class AnnotatedText { > > As far as I can see, this class is always parameterized with Style. Do you foresee any other types of annotations being used with it? I removed that generic in commit 01afad6. This somewhat simplified the code. Note that later `AnnotatedText` might be used for automated syntax highlighting, which is orthogonal to snippet markup. I hope that non-generic `AnnotatedText` will be expressive enough to withstand that extra use case. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Wed Jul 28 14:40:55 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 28 Jul 2021 14:40:55 GMT Subject: RFR: 8266666: Implementation for snippets [v5] In-Reply-To: References: Message-ID: > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision: - Change AnnotatedText to StyledText Renames the class, removes its generic parameter, and changes the related terminology from "annotate" to "style". - Restructure ...toolkit.taglets.snippet.** packages This commit moves the contents of the jdk.javadoc.internal.doclets.toolkit.taglets.snippet.{action,parser,text} packages into the jdk.javadoc.internal.doclets.toolkit.taglets.snippet package. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/34b274cb..01afad63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=03-04 Stats: 1087 lines in 18 files changed: 513 ins; 540 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From github.com+7806504+liach at openjdk.java.net Wed Jul 28 15:34:40 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 28 Jul 2021 15:34:40 GMT Subject: RFR: 8266666: Implementation for snippets [v5] In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 14:40:55 GMT, Pavel Rappo wrote: >> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. > > Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision: > > - Change AnnotatedText to StyledText > > Renames the class, removes its generic parameter, and changes the related terminology from "annotate" to "style". > - Restructure ...toolkit.taglets.snippet.** packages > > This commit moves the contents of the jdk.javadoc.internal.doclets.toolkit.taglets.snippet.{action,parser,text} packages into the jdk.javadoc.internal.doclets.toolkit.taglets.snippet package. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Action.java line 37: > 35: * deletion without notice. > 36: */ > 37: // FIXME: uncomment /* sealed */ when minimum boot version >= 17 Do we still have to wait? Currently `java.lang.reflect.Executable` and `java.lang.constant.ClassDesc` are already sealed. I wonder if uncommenting here is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From cushon at openjdk.java.net Wed Jul 28 15:56:11 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Wed, 28 Jul 2021 15:56:11 GMT Subject: RFR: 8261088: Repeatable annotations without @Target cannot have containers that target module declarations [v4] In-Reply-To: <5aDBzJlzTWVrxfvLJfya21s-8t2j299igPflTCLRRHc=.bdd1767a-5cb7-4c65-be6c-292bb17ab418@github.com> References: <5aDBzJlzTWVrxfvLJfya21s-8t2j299igPflTCLRRHc=.bdd1767a-5cb7-4c65-be6c-292bb17ab418@github.com> Message-ID: > Please review this fix to consolidate handling of default `@Target`s for repeated annotations, and permit repeatable annotations without an `@Target` to have container annotations that explicitly target `MODULE`. Liam Miller-Cushon 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 one additional commit since the last revision: 8261088: Repeatable annotations without @Target cannot have containers that target module declarations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2412/files - new: https://git.openjdk.java.net/jdk/pull/2412/files/322a709e..01540967 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2412&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2412&range=02-03 Stats: 97445 lines in 1942 files changed: 51560 ins; 35908 del; 9977 mod Patch: https://git.openjdk.java.net/jdk/pull/2412.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2412/head:pull/2412 PR: https://git.openjdk.java.net/jdk/pull/2412 From prappo at openjdk.java.net Wed Jul 28 17:02:40 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 28 Jul 2021 17:02:40 GMT Subject: RFR: 8266666: Implementation for snippets [v5] In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 15:31:11 GMT, liach wrote: >> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision: >> >> - Change AnnotatedText to StyledText >> >> Renames the class, removes its generic parameter, and changes the related terminology from "annotate" to "style". >> - Restructure ...toolkit.taglets.snippet.** packages >> >> This commit moves the contents of the jdk.javadoc.internal.doclets.toolkit.taglets.snippet.{action,parser,text} packages into the jdk.javadoc.internal.doclets.toolkit.taglets.snippet package. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Action.java line 37: > >> 35: * deletion without notice. >> 36: */ >> 37: // FIXME: uncomment /* sealed */ when minimum boot version >= 17 > > Do we still have to wait? Currently `java.lang.reflect.Executable` and `java.lang.constant.ClassDesc` are already sealed. I wonder if uncommenting here is fine. Unlike java.base, which the types you mentioned belong to, jdk.javadoc is built using boot JDK. If the JDK being built is of version N, then boot JDK is of version N-1 or N-2. Typically, the minimum version of boot JDK in the mainline is bumped in a few weeks time after GA has been released. If I uncommented those FIXMEs now, I would see this: Compiling 241 files for BUILD_jdk.javadoc.interim src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Action.java:38: error: sealed classes are a preview feature and are disabled by default. public sealed interface Action permits AddStyle, Bookmark, Replace { ^ (use --enable-preview to enable sealed classes) src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Action.java:38: error: '{' expected public sealed interface Action permits AddStyle, Bookmark, Replace { ^ 2 errors Currently in the mainline, java.base is built by JDK 18 and jdk.javadoc is built by JDK 16. The latter is because JDK 17 has not been released yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From cushon at openjdk.java.net Wed Jul 28 18:24:36 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Wed, 28 Jul 2021 18:24:36 GMT Subject: Integrated: 8261088: Repeatable annotations without @Target cannot have containers that target module declarations In-Reply-To: <5aDBzJlzTWVrxfvLJfya21s-8t2j299igPflTCLRRHc=.bdd1767a-5cb7-4c65-be6c-292bb17ab418@github.com> References: <5aDBzJlzTWVrxfvLJfya21s-8t2j299igPflTCLRRHc=.bdd1767a-5cb7-4c65-be6c-292bb17ab418@github.com> Message-ID: On Thu, 4 Feb 2021 20:53:21 GMT, Liam Miller-Cushon wrote: > Please review this fix to consolidate handling of default `@Target`s for repeated annotations, and permit repeatable annotations without an `@Target` to have container annotations that explicitly target `MODULE`. This pull request has now been integrated. Changeset: 60c11fef Author: Liam Miller-Cushon URL: https://git.openjdk.java.net/jdk/commit/60c11fef006124e6c2be6d958c78dc344bb777d5 Stats: 88 lines in 4 files changed: 66 ins; 16 del; 6 mod 8261088: Repeatable annotations without @Target cannot have containers that target module declarations Reviewed-by: jfranck ------------- PR: https://git.openjdk.java.net/jdk/pull/2412 From jlahoda at openjdk.java.net Thu Jul 29 13:21:42 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 29 Jul 2021 13:21:42 GMT Subject: RFR: JDK-8270060: (jdeprscan) tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java failed with class file for jdk.internal.util.random.RandomSupport not found Message-ID: The base problem for the test failure was: https://bugs.openjdk.java.net/browse/JDK-8270075 As that was fixed, and the change was propagated to the ct.sym historical data, the test should be passing again, and it no longer needs to be problem listed. So this patch removes the test from the `ProblemList.txt`. ------------- Commit messages: - JDK-8270060: (jdeprscan) tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java failed with class file for jdk.internal.util.random.RandomSupport not found Changes: https://git.openjdk.java.net/jdk/pull/4933/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4933&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270060 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4933.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4933/head:pull/4933 PR: https://git.openjdk.java.net/jdk/pull/4933 From sundar at openjdk.java.net Thu Jul 29 14:26:29 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 29 Jul 2021 14:26:29 GMT Subject: RFR: JDK-8270060: (jdeprscan) tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java failed with class file for jdk.internal.util.random.RandomSupport not found In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 13:15:05 GMT, Jan Lahoda wrote: > The base problem for the test failure was: > https://bugs.openjdk.java.net/browse/JDK-8270075 > > As that was fixed, and the change was propagated to the ct.sym historical data, the test should be passing again, and it no longer needs to be problem listed. So this patch removes the test from the `ProblemList.txt`. Marked as reviewed by sundar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4933 From vromero at openjdk.java.net Thu Jul 29 15:12:31 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 29 Jul 2021 15:12:31 GMT Subject: RFR: JDK-8270060: (jdeprscan) tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java failed with class file for jdk.internal.util.random.RandomSupport not found In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 13:15:05 GMT, Jan Lahoda wrote: > The base problem for the test failure was: > https://bugs.openjdk.java.net/browse/JDK-8270075 > > As that was fixed, and the change was propagated to the ct.sym historical data, the test should be passing again, and it no longer needs to be problem listed. So this patch removes the test from the `ProblemList.txt`. Marked as reviewed by vromero (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4933 From prappo at openjdk.java.net Thu Jul 29 15:19:38 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 29 Jul 2021 15:19:38 GMT Subject: RFR: 8266666: Implementation for snippets [v5] In-Reply-To: References: Message-ID: <_ZEX6k-0YBDRo3FwRGvE7p68E69hTDfGJ8DxG0veoVk=.d62a9715-1dcc-4510-bd41-6d0e25d3e0bb@github.com> On Fri, 23 Jul 2021 20:13:56 GMT, Jonathan Gibbons wrote: > the existing seeTagToContent handles all flavors of @see tag, and {@link}. All but fake ones. The `seeTagToContent` method uses the path (`DocTreePath`) of the `see` tag being passed. In the case of snippet markup, there's no such tag; so there's noting to derive the path from. Even if we synthesized such a tag, we would need to carefully embed it into the doc comment tree for the duration of the call to `seeTagToContent`, which is way too complicated and might have unforeseen effects. I would appreciate it, if you could help me refactor this code. ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From hannesw at openjdk.java.net Thu Jul 29 16:02:34 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 29 Jul 2021 16:02:34 GMT Subject: RFR: 8266666: Implementation for snippets [v5] In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 14:40:55 GMT, Pavel Rappo wrote: >> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. > > Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision: > > - Change AnnotatedText to StyledText > > Renames the class, removes its generic parameter, and changes the related terminology from "annotate" to "style". > - Restructure ...toolkit.taglets.snippet.** packages > > This commit moves the contents of the jdk.javadoc.internal.doclets.toolkit.taglets.snippet.{action,parser,text} packages into the jdk.javadoc.internal.doclets.toolkit.taglets.snippet package. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 868: > 866: > 867: pre.snippet { > 868: background-color: #e8e8e8; I think the plain gray clashes a bit with the javadoc gray scale which has a hint of blue in it. Something like the value below works better within that scale. Suggestion: background-color: #ebecee; ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From hannesw at openjdk.java.net Thu Jul 29 16:06:35 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 29 Jul 2021 16:06:35 GMT Subject: RFR: 8266666: Implementation for snippets [v5] In-Reply-To: References: Message-ID: On Wed, 28 Jul 2021 14:40:55 GMT, Pavel Rappo wrote: >> This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. > > Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision: > > - Change AnnotatedText to StyledText > > Renames the class, removes its generic parameter, and changes the related terminology from "annotate" to "style". > - Restructure ...toolkit.taglets.snippet.** packages > > This commit moves the contents of the jdk.javadoc.internal.doclets.toolkit.taglets.snippet.{action,parser,text} packages into the jdk.javadoc.internal.doclets.toolkit.taglets.snippet package. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css line 884: > 882: > 883: pre.snippet .highlighted { > 884: background-color: sandybrown; Here I think the color clashes a bit with the very similar orange we use for table headers/tabs. I'm not really sure about this one, but maybe a "watered down" orange with a similar tone but less saturation could work. Suggestion: background-color: #f7c590; ------------- PR: https://git.openjdk.java.net/jdk/pull/4795 From prappo at openjdk.java.net Thu Jul 29 16:19:14 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 29 Jul 2021 16:19:14 GMT Subject: RFR: 8266666: Implementation for snippets [v6] In-Reply-To: References: Message-ID: <_WcbE9LIV4ufvzW0LdYfHCcJ5x9Z9d4TLh3gGG3ethg=.3fc9b092-bba3-4315-8767-91167959a1a0@github.com> > This PR implements JEP 413 "Code Snippets in Java API Documentation", which hasn't been yet proposed to target JDK 18. The PR starts as a squashed merge of the https://github.com/openjdk/jdk-sandbox/tree/jdk.javadoc/snippets branch. Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision: - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Co-authored-by: Hannes Wallnoefer - Update src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Co-authored-by: Hannes Wallnoefer ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4795/files - new: https://git.openjdk.java.net/jdk/pull/4795/files/01afad63..0a47e9c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4795&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4795/head:pull/4795 PR: https://git.openjdk.java.net/jdk/pull/4795 From rriggs at openjdk.java.net Thu Jul 29 16:44:55 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 29 Jul 2021 16:44:55 GMT Subject: [jdk17] RFR: 8271489: (doc) Clarify Filter Factory example Message-ID: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com> Improve the clarity of comments in the ObjectInputFilter FilterInThread example. ------------- Commit messages: - 8271489: (doc) Clarify Filter Factory example - 8270398: Enhance canonicalization - 8270404: Better canonicalization - Merge - Merge - 8263531: Remove unused buffer int - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" - 8269763: The JEditorPane is blank after JDK-8265167 - 8265580: Enhanced style for RTF kit - 8265574: Improve handling of sheets - ... and 15 more: https://git.openjdk.java.net/jdk17/compare/c1304519...650e1561 Changes: https://git.openjdk.java.net/jdk17/pull/292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=292&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271489 Stats: 1001 lines in 42 files changed: 625 ins; 181 del; 195 mod Patch: https://git.openjdk.java.net/jdk17/pull/292.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/292/head:pull/292 PR: https://git.openjdk.java.net/jdk17/pull/292 From darcy at openjdk.java.net Thu Jul 29 17:21:30 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 29 Jul 2021 17:21:30 GMT Subject: RFR: JDK-8270060: (jdeprscan) tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java failed with class file for jdk.internal.util.random.RandomSupport not found In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 13:15:05 GMT, Jan Lahoda wrote: > The base problem for the test failure was: > https://bugs.openjdk.java.net/browse/JDK-8270075 > > As that was fixed, and the change was propagated to the ct.sym historical data, the test should be passing again, and it no longer needs to be problem listed. So this patch removes the test from the `ProblemList.txt`. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4933 From rriggs at openjdk.java.net Thu Jul 29 17:46:36 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 29 Jul 2021 17:46:36 GMT Subject: [jdk17] Withdrawn: 8271489: (doc) Clarify Filter Factory example In-Reply-To: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com> References: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com> Message-ID: <4o8A0bH9cVUSjB1lO6rW6Z3QT1KTxpu9Z0IaWK3c_-g=.25c55618-f4b9-46d6-9e4e-39674df24ca9@github.com> On Thu, 29 Jul 2021 16:36:21 GMT, Roger Riggs wrote: > Improve the clarity of comments in the ObjectInputFilter FilterInThread example. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk17/pull/292 From jlahoda at openjdk.java.net Fri Jul 30 08:02:33 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 30 Jul 2021 08:02:33 GMT Subject: Integrated: JDK-8270060: (jdeprscan) tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java failed with class file for jdk.internal.util.random.RandomSupport not found In-Reply-To: References: Message-ID: On Thu, 29 Jul 2021 13:15:05 GMT, Jan Lahoda wrote: > The base problem for the test failure was: > https://bugs.openjdk.java.net/browse/JDK-8270075 > > As that was fixed, and the change was propagated to the ct.sym historical data, the test should be passing again, and it no longer needs to be problem listed. So this patch removes the test from the `ProblemList.txt`. This pull request has now been integrated. Changeset: b59418f4 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/b59418f47d8e69f6aec3411b105e2512d19f6cd1 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8270060: (jdeprscan) tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java failed with class file for jdk.internal.util.random.RandomSupport not found Reviewed-by: sundar, vromero, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/4933 From nlisker at gmail.com Thu Jul 22 21:42:07 2021 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 22 Jul 2021 21:42:07 -0000 Subject: Slow compilation with a lot of type inference In-Reply-To: <7ab96f26-314a-9f17-94bd-2f69174e4183@oracle.com> References: <1a1fa0b8-5dae-0495-931d-bc84f579de9f@oracle.com> <7ab96f26-314a-9f17-94bd-2f69174e4183@oracle.com> Message-ID: I understand. Thanks. - Nir On Thu, Jul 22, 2021 at 1:39 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi, > we already have entries for those: > > https://bugs.openjdk.java.net/browse/JDK-8152289 > > and > > https://bugs.openjdk.java.net/browse/JDK-8221301 > > In javac we are doing a lot of heroics to try and keep the space of > inference variable as small as possible, by aggressively de-duping > inference variables where possible. This strategy works well in cases like: > > a(b(c(d(...))))) > > But in cases like the ones you report (or those in the JBS issues > above), which have a shape like: > > a(b(), c(), d(), e() ... ) > > We do not yet perform any de-duping, so the inference engine has to run > with a very big set of (possibly very similarly looking) inference > variables. Performing incorporation will end up setting similarly > looking bounds on the inference variables of the outer a() call, which > all have to be validated, and so on and so forth. > > I think de-duping cases like these is still possible, but it's a change > that probably cuts much deeper into the inference engine - and we have > been holding off on that when we fixed the main inference performance > issue in Java 8/9, although I understand that with the Collection > factories, idioms like these just got a lot more common. > > Cheers > Maurizio > > > > On 22/07/2021 03:03, Vicente Romero wrote: > > Hi Nir, > > > > We have done a lot of work to speed up inference, unfortunately it is > > always possible to generate code that will make the inference engine > > look bad, please file a bug in our JIRA system with all of your > > findings and we will get to it when possible, > > > > Thanks, > > Vicente > > > > On 7/19/21 1:13 PM, Nir Lisker wrote: > >> Hi, > >> > >> I have recently submitted an Eclipse bug [1] regarding very slow > >> compilation when a lot of type inference is required. The report > >> includes an example case, which looks like: > >> > >> public static final Map DESC = Map.ofEntries( > >> Map.entry("A", "B"), > >> Map.entry("A", "B"), > >> Map.entry("A", "B"), > >> // many more of these > >> ); > >> > >> The Eclipse developer shows that the slowness happens in javac as > >> well. I understand that every entry needs to be looked at to find the > >> type for Map.ofEntries, and the problem can be resolved by adding > >> Map.ofEntries, but I thought it's worth asking here too. > >> > >> Is this considered normal behavior? > >> > >> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=574732 > >> > >> > >> - Nir > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: