From jlahoda at openjdk.org Wed Mar 6 21:26:51 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 6 Mar 2024 21:26:51 GMT Subject: RFR: 8327476: Upgrade JLine to 3.25.1 Message-ID: This is a patch that: a) upgrades the JLine inside the JDK to 3.25.1 b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal the patch is here: https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff I've also cleaned the patch a little removing most of the changes for the rename. The result is here: https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff ------------- Depends on: https://git.openjdk.org/jdk/pull/18106 Commit messages: - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 - Re-enabling the exec provider. - Cleanup. - Fixing test. - Fixing Crl-C/VINTR handling on Linux. - Cleanup. - Enabling native access for jdk.internal.le. - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 - Ctrl-C should not kill JShell. - ... and 8 more: https://git.openjdk.org/jdk/compare/e30e4529...d6c2072f Changes: https://git.openjdk.org/jdk/pull/18142/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18142&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327476 Stats: 12893 lines in 142 files changed: 5623 ins; 5298 del; 1972 mod Patch: https://git.openjdk.org/jdk/pull/18142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18142/head:pull/18142 PR: https://git.openjdk.org/jdk/pull/18142 From duke at openjdk.org Thu Mar 7 12:14:54 2024 From: duke at openjdk.org (ExE Boss) Date: Thu, 7 Mar 2024 12:14:54 GMT Subject: RFR: 8327476: Upgrade JLine to 3.25.1 In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 21:20:50 GMT, Jan Lahoda wrote: > This is a patch that: > a) upgrades the JLine inside the JDK to 3.25.1 > b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend > > Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: > - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 > - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily > > There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: > https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal > the patch is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff > > I've also cleaned the patch a little removing most of the changes for the rename. The result is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractPty.java line 214: > 212: return descriptor; > 213: } > 214: } Since?this is?a?part of?the?JDK, `jdk.internal.access.JavaIOFileDescriptorAccess` can?be?used instead?of?reflection. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18142#discussion_r1516053385 From jlahoda at openjdk.org Thu Mar 7 21:30:54 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 7 Mar 2024 21:30:54 GMT Subject: RFR: 8327476: Upgrade JLine to 3.25.1 In-Reply-To: References:

Message-ID: On Thu, 7 Mar 2024 12:11:19 GMT, ExE Boss wrote: >> This is a patch that: >> a) upgrades the JLine inside the JDK to 3.25.1 >> b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend >> >> Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: >> - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 >> - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily >> >> There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal >> the patch is here: >> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff >> >> I've also cleaned the patch a little removing most of the changes for the rename. The result is here: >> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff > > src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractPty.java line 214: > >> 212: return descriptor; >> 213: } >> 214: } > > Since?this is?a?part of?the?JDK, `jdk.internal.access.JavaIOFileDescriptorAccess` can?be?used instead?of?reflection. As this originates in the JLine itself, I would rather avoid doing changes that are unnecessary. Because as a consequence, we would need to re-apply the changes for every upgrade. I believe this code is practically not used in our context, so I don't think it really matters to make it nice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18142#discussion_r1516856805 From ihse at openjdk.org Fri Mar 8 07:59:54 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 8 Mar 2024 07:59:54 GMT Subject: RFR: 8327476: Upgrade JLine to 3.25.1 In-Reply-To: References: Message-ID: On Wed, 6 Mar 2024 21:20:50 GMT, Jan Lahoda wrote: > This is a patch that: > a) upgrades the JLine inside the JDK to 3.25.1 > b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend > > Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: > - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 > - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily > > There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: > https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal > the patch is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff > > I've also cleaned the patch a little removing most of the changes for the rename. The result is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18142#pullrequestreview-1924287821 From jlahoda at openjdk.org Fri Mar 8 08:45:13 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 8 Mar 2024 08:45:13 GMT Subject: RFR: 8326333: jshell completion on arrays is incomplete Message-ID: Inside jshell, arrays don't show `Object` method in array code completion, i.e.: jshell> String[] arr = null; arr ==> null jshell> arr. will only show `length`. This patch adds `j.l.Object` methods to the suggestions for arrays. ------------- Commit messages: - 8326333: jshell completion on arrays is incomplete Changes: https://git.openjdk.org/jdk/pull/18163/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18163&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326333 Stats: 38 lines in 2 files changed: 26 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/18163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18163/head:pull/18163 PR: https://git.openjdk.org/jdk/pull/18163 From jlahoda at openjdk.org Fri Mar 8 11:28:10 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 8 Mar 2024 11:28:10 GMT Subject: RFR: 8327476: Upgrade JLine to 3.25.1 [v2] In-Reply-To: References: Message-ID: <-KQlwb5Af-5yakz-TpbOhZOeDGdzf8cbHjPDmHwTIJU=.01f547d0-0b8d-4da4-a7e1-f966ed887d82@github.com> > This is a patch that: > a) upgrades the JLine inside the JDK to 3.25.1 > b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend > > Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: > - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 > - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily > > There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: > https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal > the patch is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff > > I've also cleaned the patch a little removing most of the changes for the rename. The result is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1 - Apply suggestions from code review Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 - Reflecting review feedback. - Updating copyright headers. - Re-enabling the exec provider. - Cleanup. - Fixing test. - Fixing Crl-C/VINTR handling on Linux. - ... and 14 more: https://git.openjdk.org/jdk/compare/e772e781...d6c2072f ------------- Changes: https://git.openjdk.org/jdk/pull/18142/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18142&range=01 Stats: 13023 lines in 150 files changed: 5727 ins; 5307 del; 1989 mod Patch: https://git.openjdk.org/jdk/pull/18142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18142/head:pull/18142 PR: https://git.openjdk.org/jdk/pull/18142 From jlahoda at openjdk.org Fri Mar 8 11:52:11 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 8 Mar 2024 11:52:11 GMT Subject: RFR: 8327476: Upgrade JLine to 3.25.1 [v3] In-Reply-To: References: Message-ID: > This is a patch that: > a) upgrades the JLine inside the JDK to 3.25.1 > b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend > > Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: > - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 > - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily > > There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: > https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal > the patch is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff > > I've also cleaned the patch a little removing most of the changes for the rename. The result is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into jline-upgrade-3.25.1 - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1 - Apply suggestions from code review Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 - Reflecting review feedback. - Updating copyright headers. - Re-enabling the exec provider. - Cleanup. - Fixing test. - ... and 15 more: https://git.openjdk.org/jdk/compare/27a03e0d...fe8d5a42 ------------- Changes: https://git.openjdk.org/jdk/pull/18142/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18142&range=02 Stats: 12893 lines in 142 files changed: 5623 ins; 5298 del; 1972 mod Patch: https://git.openjdk.org/jdk/pull/18142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18142/head:pull/18142 PR: https://git.openjdk.org/jdk/pull/18142 From gli at openjdk.org Sat Mar 9 04:56:56 2024 From: gli at openjdk.org (Guoxiong Li) Date: Sat, 9 Mar 2024 04:56:56 GMT Subject: RFR: 8326333: jshell completion on arrays is incomplete In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 08:40:19 GMT, Jan Lahoda wrote: > Inside jshell, arrays don't show `Object` method in array code completion, i.e.: > > jshell> String[] arr = null; > arr ==> null > > jshell> arr. > > > will only show `length`. This patch adds `j.l.Object` methods to the suggestions for arrays. The copyright of `SourceCodeAnalysisImpl.java` needs to be adjusted too. Thanks. test/langtools/jdk/jshell/CompletionSuggestionTest.java line 814: > 812: } > 813: > 814: //JDK-8326333 Such simple bug-id seems unnecessary or uncomplete. It is better to privode some description content. ------------- Changes requested by gli (Committer). PR Review: https://git.openjdk.org/jdk/pull/18163#pullrequestreview-1926091601 PR Review Comment: https://git.openjdk.org/jdk/pull/18163#discussion_r1518478351 From aturbanov at openjdk.org Mon Mar 11 18:16:54 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 11 Mar 2024 18:16:54 GMT Subject: RFR: 8325936: jshell - crash on 'new Object().""' In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 16:55:31 GMT, Hannes Greule wrote: > This fixes a crash in jshell when the target of a StringTemplate is not a processor. We only look up the `process` method if the type is actually a processor. The added test case fails without that fix. > > Please let me know what you think of this fix, and if there are things that should be changed. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4482: > 4480: Type interfaceType = types.asSuper(processorType, syms.processorType.tsym); > 4481: > 4482: if (interfaceType == null) { Suggestion: if (interfaceType == null) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17876#discussion_r1520210961 From duke at openjdk.org Tue Mar 12 01:52:45 2024 From: duke at openjdk.org (SUN Guoyun) Date: Tue, 12 Mar 2024 01:52:45 GMT Subject: RFR: 8303625: jdk/jshell/JdiFailingLaunchExecutionControlTest.java fail with -Xcomp [v2] In-Reply-To: References: Message-ID: > This tests failed with VM_OPTIONS=-Xcomp and CONF=fastdebug on the LOONGARCH64 architecture because JdiExecutionControlProvider`s timeout. > jdk/jshell/JdiFailingLaunchExecutionControlTest.java > jdk/jshell/JdiFailingListenExecutionControlTest.java > > This PR fix the issue, Please help review it. > > Thanks. SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision: 8303625: jdk/jshell/JdiFailingLaunchExecutionControlTest.java fail with -Xcomp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12873/files - new: https://git.openjdk.org/jdk/pull/12873/files/5548ebdb..c7bfd22a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12873&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12873&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12873.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12873/head:pull/12873 PR: https://git.openjdk.org/jdk/pull/12873 From duke at openjdk.org Tue Mar 12 07:34:54 2024 From: duke at openjdk.org (SUN Guoyun) Date: Tue, 12 Mar 2024 07:34:54 GMT Subject: RFR: 8303625: jdk/jshell/JdiFailingLaunchExecutionControlTest.java fail with -Xcomp [v3] In-Reply-To: References: Message-ID: > This tests failed with VM_OPTIONS=-Xcomp and CONF=fastdebug on the LOONGARCH64 architecture because JdiExecutionControlProvider`s timeout. > jdk/jshell/JdiFailingLaunchExecutionControlTest.java > jdk/jshell/JdiFailingListenExecutionControlTest.java > > This PR fix the issue, Please help review it. > > Thanks. SUN Guoyun 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 three additional commits since the last revision: - Merge branch 'openjdk:master' into 8303625 - 8303625: jdk/jshell/JdiFailingLaunchExecutionControlTest.java fail with -Xcomp - 8303625: jdk/jshell/JdiFailingLaunchExecutionControlTest.java fail with -Xcomp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12873/files - new: https://git.openjdk.org/jdk/pull/12873/files/c7bfd22a..3ebf660a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12873&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12873&range=01-02 Stats: 1715155 lines in 17925 files changed: 836470 ins; 696847 del; 181838 mod Patch: https://git.openjdk.org/jdk/pull/12873.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12873/head:pull/12873 PR: https://git.openjdk.org/jdk/pull/12873 From jlahoda at openjdk.org Thu Mar 14 10:31:55 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 14 Mar 2024 10:31:55 GMT Subject: RFR: 8327512: JShell does not work correctly when a class named Object or Throwable is defined Message-ID: When JShell wraps the user's snippets with additional code to make the standalone compilable units, it uses simple names to refer to `Object`, `Throwable` or `SuppressWarnings` in some cases. These may interact with user-defined class of the same names, leading to error while running the next snippet. E.g.: jshell> class Object{} | created class Object jshell> 1 | Error: | incompatible types: int cannot be converted to Object | 1 | ^ The proposal here is to use qualified names when creating the snippet wrappers, and to more carefully produce simple names when analyzing expressions (fully qualified names should be used when a class with the same simple name has been introduced in a snippet). ------------- Commit messages: - 8327512: JShell does not work correctly when a class named Object or Throwable is defined Changes: https://git.openjdk.org/jdk/pull/18295/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18295&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327512 Stats: 82 lines in 6 files changed: 74 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/18295.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18295/head:pull/18295 PR: https://git.openjdk.org/jdk/pull/18295 From jlahoda at openjdk.org Thu Mar 14 12:01:10 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 14 Mar 2024 12:01:10 GMT Subject: RFR: 8326333: jshell completion on arrays is incomplete [v2] In-Reply-To: References: Message-ID: > Inside jshell, arrays don't show `Object` method in array code completion, i.e.: > > jshell> String[] arr = null; > arr ==> null > > jshell> arr. > > > will only show `length`. This patch adds `j.l.Object` methods to the suggestions for arrays. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18163/files - new: https://git.openjdk.org/jdk/pull/18163/files/e552580b..9ce5fb1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18163&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18163&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18163/head:pull/18163 PR: https://git.openjdk.org/jdk/pull/18163 From vromero at openjdk.org Thu Mar 14 13:30:40 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 14 Mar 2024 13:30:40 GMT Subject: RFR: 8326333: jshell completion on arrays is incomplete [v2] In-Reply-To: References:

Message-ID: On Thu, 14 Mar 2024 12:01:10 GMT, Jan Lahoda wrote: >> Inside jshell, arrays don't show `Object` method in array code completion, i.e.: >> >> jshell> String[] arr = null; >> arr ==> null >> >> jshell> arr. >> >> >> will only show `length`. This patch adds `j.l.Object` methods to the suggestions for arrays. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18163#pullrequestreview-1936713017 From jlahoda at openjdk.org Mon Mar 18 08:27:31 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 18 Mar 2024 08:27:31 GMT Subject: Integrated: 8326333: jshell completion on arrays is incomplete In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 08:40:19 GMT, Jan Lahoda wrote: > Inside jshell, arrays don't show `Object` method in array code completion, i.e.: > > jshell> String[] arr = null; > arr ==> null > > jshell> arr. > > > will only show `length`. This patch adds `j.l.Object` methods to the suggestions for arrays. This pull request has now been integrated. Changeset: 48717d63 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/48717d63cc58f693f0917e61eafd672cd6af02ed Stats: 39 lines in 2 files changed: 26 ins; 7 del; 6 mod 8326333: jshell completion on arrays is incomplete Reviewed-by: vromero ------------- PR: https://git.openjdk.org/jdk/pull/18163 From hgreule at openjdk.org Tue Mar 19 18:48:26 2024 From: hgreule at openjdk.org (Hannes Greule) Date: Tue, 19 Mar 2024 18:48:26 GMT Subject: RFR: 8328536: javac - crash on unknown type referenced in yield statement Message-ID: Pasting e.g. I m(I i, int x) { return switch (x) { default -> i; }; } in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch. Javac will not crash but swallow the exception, and create a file containing the command line options. I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally. ------------- Commit messages: - Fix jshell crash on unknown type in switch yield Changes: https://git.openjdk.org/jdk/pull/18383/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18383&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328536 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18383/head:pull/18383 PR: https://git.openjdk.org/jdk/pull/18383 From jlahoda at openjdk.org Wed Mar 20 18:55:38 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 20 Mar 2024 18:55:38 GMT Subject: RFR: 8327476: Upgrade JLine to 3.25.1 [v4] In-Reply-To: References: Message-ID: > This is a patch that: > a) upgrades the JLine inside the JDK to 3.25.1 > b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend > > Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: > - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 > - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily > > There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: > https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm > https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal > the patch is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff > > I've also cleaned the patch a little removing most of the changes for the rename. The result is here: > https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - Merge branch 'master' into jline-upgrade-3.25.1 - Merge branch 'master' into jline-upgrade-3.25.1 - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1 - Apply suggestions from code review Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 - Reflecting review feedback. - Updating copyright headers. - Re-enabling the exec provider. - Cleanup. - ... and 16 more: https://git.openjdk.org/jdk/compare/e5e7cd20...c8097592 ------------- Changes: https://git.openjdk.org/jdk/pull/18142/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18142&range=03 Stats: 12892 lines in 142 files changed: 5623 ins; 5297 del; 1972 mod Patch: https://git.openjdk.org/jdk/pull/18142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18142/head:pull/18142 PR: https://git.openjdk.org/jdk/pull/18142 From vromero at openjdk.org Thu Mar 21 21:10:24 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 21 Mar 2024 21:10:24 GMT Subject: RFR: 8327476: Upgrade JLine to 3.25.1 [v4] In-Reply-To: References:

Message-ID: <9HglANKn03Vqqogk_CBayDACj8ezpVpq0ule1EmCsgQ=.8516a0e2-bdd1-4bf0-8bea-591076baf451@github.com> On Wed, 20 Mar 2024 18:55:38 GMT, Jan Lahoda wrote: >> This is a patch that: >> a) upgrades the JLine inside the JDK to 3.25.1 >> b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend >> >> Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: >> - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 >> - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily >> >> There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal >> the patch is here: >> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff >> >> I've also cleaned the patch a little removing most of the changes for the rename. The result is here: >> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: > > - Merge branch 'master' into jline-upgrade-3.25.1 > - Merge branch 'master' into jline-upgrade-3.25.1 > - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 > - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1 > - Apply suggestions from code review > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> > - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 > - Reflecting review feedback. > - Updating copyright headers. > - Re-enabling the exec provider. > - Cleanup. > - ... and 16 more: https://git.openjdk.org/jdk/compare/e5e7cd20...c8097592 src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/CLibrary.java line 497: > 495: sb.append("Unable to find openpty native method in static libraries and unable to load the util library."); > 496: List suppressed = new ArrayList<>(); > 497: try { This entire section trying to load libutil is quite complex. For a start, I'd recommend you break it out into a separate method `loadLibUtil` or something like that, to make this clearer. src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/CLibrary.java line 504: > 502: } > 503: if (openPtyAddr.isEmpty()) { > 504: String libUtilPath = System.getProperty("jdk.internal.org.jline.ffm.libutil"); Wait a minute. If I get this right, then you can pass `-Djdk.internal.org.jline.ffm.libutil=mydodgylib.so` as command line, and have the JDK load any arbitrary library? That sounds super bad from a security perspective. I recommend you remove this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18142#discussion_r1535461403 PR Review Comment: https://git.openjdk.org/jdk/pull/18142#discussion_r1535462748 From ihse at openjdk.org Fri Mar 22 12:07:25 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 22 Mar 2024 12:07:25 GMT Subject: RFR: 8327476: Upgrade JLine to 3.25.1 [v4] In-Reply-To: References:

Message-ID: On Wed, 20 Mar 2024 18:55:38 GMT, Jan Lahoda wrote: >> This is a patch that: >> a) upgrades the JLine inside the JDK to 3.25.1 >> b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend >> >> Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are: >> - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945 >> - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily >> >> There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects: >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm >> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal >> the patch is here: >> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff >> >> I've also cleaned the patch a little removing most of the changes for the rename. The result is here: >> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: > > - Merge branch 'master' into jline-upgrade-3.25.1 > - Merge branch 'master' into jline-upgrade-3.25.1 > - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 > - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1 > - Apply suggestions from code review > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> > - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1 > - Reflecting review feedback. > - Updating copyright headers. > - Re-enabling the exec provider. > - Cleanup. > - ... and 16 more: https://git.openjdk.org/jdk/compare/e5e7cd20...c8097592 Aha, now I understand! The new files in `jdk.internal.org.jline.terminal.impl.ffm` comes from upstream. I thought they were additions made by you. I guess that means my comments are still valid, but should be asked upstream instead. And that you don't need to address them here. For security reasons, though, I still recommend you remove the generic library loading part. JLine might think they can have such functionality (even if it is crazy), but we can't ship it as part of the JDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18142#issuecomment-2014944780 From jlahoda at openjdk.org Fri Mar 22 18:31:42 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 22 Mar 2024 18:31:42 GMT Subject: RFR: 8328627: JShell documentation should be clearer about "remote runtime system" [v2] In-Reply-To: References: Message-ID: > This change attempts to more clearly explain the difference between `-J` and `-R` for JShell. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Updating the documentation as suggested. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18450/files - new: https://git.openjdk.org/jdk/pull/18450/files/b1b24aca..97cd0232 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18450&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18450&range=00-01 Stats: 33 lines in 2 files changed: 2 ins; 5 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/18450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18450/head:pull/18450 PR: https://git.openjdk.org/jdk/pull/18450 From canpodeyiji at gmail.com Fri Mar 22 16:32:45 2024 From: canpodeyiji at gmail.com (iseki) Date: Sat, 23 Mar 2024 00:32:45 +0800 Subject: RFR: 8289613: Drop use of Thread.stop in jshell In-Reply-To: References: Message-ID: After removing it, how can users forcibly terminate a thread in the same manner as JShell does, especially when some of the code belongs to the standard library and cannot be altered? Is it necessary to instrument the code on-the-fly? Just like your current working? From jlahoda at openjdk.org Fri Mar 22 19:38:44 2024 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 22 Mar 2024 19:38:44 GMT Subject: RFR: 8328627: JShell documentation should be clearer about "remote runtime system" [v3] In-Reply-To: References: Message-ID: > This change attempts to more clearly explain the difference between `-J` and `-R` for JShell. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Updated as suggested. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18450/files - new: https://git.openjdk.org/jdk/pull/18450/files/97cd0232..6f8651dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18450&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18450&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/18450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18450/head:pull/18450 PR: https://git.openjdk.org/jdk/pull/18450 From jjg at openjdk.org Wed Mar 27 22:08:57 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 27 Mar 2024 22:08:57 GMT Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments Message-ID: Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option. The work can be thought of as in 3 parts: 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not. 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The procedure for handling dangling doc comments is described in this comment in `JavacParser`. * Dangling documentation comments are handled as follows. * 1. {@code Scanner} adds all doc comments to a queue of * recent doc comments. The queue is flushed whenever * it is known that the recent doc comments should be * ignored and should not cause any warnings. * 2. The primary documentation comment is the one obtained * from the first token of any declaration. * (using {@code token.getDocComment()}. * 3. At the end of the "signature" of the declaration * (that is, before any initialization or body for the * declaration) any other "recent" comments are saved * in a map using the primary comment as a key, * using this method, {@code saveDanglingComments}. * 4. When the tree node for the declaration is finally * available, and the primary comment, if any, * is "attached", (in {@link #attach}) any related * dangling comments are also attached to the tree node * by registering them using the {@link #deferredLintHandler}. * 5. (Later) Warnings may be genereated for the dangling * comments, subject to the {@code -Xlint} and * {@code @SuppressWarnings}. 3. Updates to the make files to disable the warnings in modules for which the warning is generated. This is often because of the confusing use of `/**` to create box or other standout comments. ------------- Commit messages: - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments Changes: https://git.openjdk.org/jdk/pull/18527/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303689 Stats: 477 lines in 60 files changed: 368 ins; 5 del; 104 mod Patch: https://git.openjdk.org/jdk/pull/18527.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527 PR: https://git.openjdk.org/jdk/pull/18527 From prappo at openjdk.org Wed Mar 27 22:44:31 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 27 Mar 2024 22:44:31 GMT Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments In-Reply-To: References: Message-ID: <7vkdZb7QDt106_k7_i7PrYzCYuEwTT-P2l4VxDOrNQk=.e98a3d16-8be0-4194-acd5-94eff555adce@github.com> On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote: > Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option. > > The work can be thought of as in 3 parts: > > 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not. > > 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The procedure for handling dangling doc comments is described in this comment in `JavacParser`. > > * Dangling documentation comments are handled as follows. > * 1. {@code Scanner} adds all doc comments to a queue of > * recent doc comments. The queue is flushed whenever > * it is known that the recent doc comments should be > * ignored and should not cause any warnings. > * 2. The primary documentation comment is the one obtained > * from the first token of any declaration. > * (using {@code token.getDocComment()}. > * 3. At the end of the "signature" of the declaration > * (that is, before any initialization or body for the > * declaration) any other "recent" comments are saved > * in a map using the primary comment as a key, > * using this method, {@code saveDanglingComments}. > * 4. When the tree node for the declaration is finally > * available, and the primary comment, if any, > * is "attached", (in {@link #attach}) any related > * dangling comments are also attached to the tree node > * by registering them using the {@link #deferredLintHandler}. > * 5. (Later) Warnings may be genereated for the dangling > * comments, subject to the {@code -Xlint} and > * {@code @SuppressWarnings}. > > > 3. Updates to the make files to disable the warnings in modules for which the > warning is generated. This is often because of the confusing use of `/**` to > create box or other standout comments. Would this be the first lint -- not doclint -- warning related to comments, let alone doc comments? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024106466 From liach at openjdk.org Wed Mar 27 22:52:32 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 27 Mar 2024 22:52:32 GMT Subject: RFR: 8328536: javac - crash on unknown type referenced in yield statement In-Reply-To: References: Message-ID: On Tue, 19 Mar 2024 17:49:32 GMT, Hannes Greule wrote: > Pasting e.g. > > I m(I i, int x) { > return switch (x) { > default -> i; > }; > } > > in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch. > > Javac will not crash but swallow the exception, and create a file containing the command line options. > > I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally. test/langtools/jdk/jshell/ToolSimpleTest.java line 1: > 1: /* You should add the bug id in the test header. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18383#discussion_r1542127628 From prappo at openjdk.org Wed Mar 27 22:55:32 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 27 Mar 2024 22:55:32 GMT Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote: > Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option. > > The work can be thought of as in 3 parts: > > 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not. > > 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The procedure for handling dangling doc comments is described in this comment in `JavacParser`. > > * Dangling documentation comments are handled as follows. > * 1. {@code Scanner} adds all doc comments to a queue of > * recent doc comments. The queue is flushed whenever > * it is known that the recent doc comments should be > * ignored and should not cause any warnings. > * 2. The primary documentation comment is the one obtained > * from the first token of any declaration. > * (using {@code token.getDocComment()}. > * 3. At the end of the "signature" of the declaration > * (that is, before any initialization or body for the > * declaration) any other "recent" comments are saved > * in a map using the primary comment as a key, > * using this method, {@code saveDanglingComments}. > * 4. When the tree node for the declaration is finally > * available, and the primary comment, if any, > * is "attached", (in {@link #attach}) any related > * dangling comments are also attached to the tree node > * by registering them using the {@link #deferredLintHandler}. > * 5. (Later) Warnings may be genereated for the dangling > * comments, subject to the {@code -Xlint} and > * {@code @SuppressWarnings}. > > > 3. Updates to the make files to disable the warnings in modules for which the > warning is generated. This is often because of the confusing use of `/**` to > create box or other standout comments. Javadoc changes look trivially good. I only note that the javadoc man page diff contains some unrelated changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024116236 From prappo at openjdk.org Wed Mar 27 22:59:34 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 27 Mar 2024 22:59:34 GMT Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote: > Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option. > > The work can be thought of as in 3 parts: > > 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not. > > 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The procedure for handling dangling doc comments is described in this comment in `JavacParser`. > > * Dangling documentation comments are handled as follows. > * 1. {@code Scanner} adds all doc comments to a queue of > * recent doc comments. The queue is flushed whenever > * it is known that the recent doc comments should be > * ignored and should not cause any warnings. > * 2. The primary documentation comment is the one obtained > * from the first token of any declaration. > * (using {@code token.getDocComment()}. > * 3. At the end of the "signature" of the declaration > * (that is, before any initialization or body for the > * declaration) any other "recent" comments are saved > * in a map using the primary comment as a key, > * using this method, {@code saveDanglingComments}. > * 4. When the tree node for the declaration is finally > * available, and the primary comment, if any, > * is "attached", (in {@link #attach}) any related > * dangling comments are also attached to the tree node > * by registering them using the {@link #deferredLintHandler}. > * 5. (Later) Warnings may be genereated for the dangling > * comments, subject to the {@code -Xlint} and > * {@code @SuppressWarnings}. > > > 3. Updates to the make files to disable the warnings in modules for which the > warning is generated. This is often because of the confusing use of `/**` to > create box or other standout comments. src/jdk.javadoc/share/man/javadoc.1 line 111: > 109: source code with the \f[V]javac\f[R] option \f[V]-Xlint\f[R], or more > 110: specifically, \f[V]-Xlint:dangling-doc-comments\f[R]. > 111: Within a source file, you may use suppress any warnings generated by Typo? Suggestion: Within a source file, you may suppress any warnings generated by ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1542131487 From jjg at openjdk.org Wed Mar 27 23:47:32 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 27 Mar 2024 23:47:32 GMT Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments In-Reply-To: <7vkdZb7QDt106_k7_i7PrYzCYuEwTT-P2l4VxDOrNQk=.e98a3d16-8be0-4194-acd5-94eff555adce@github.com> References: <7vkdZb7QDt106_k7_i7PrYzCYuEwTT-P2l4VxDOrNQk=.e98a3d16-8be0-4194-acd5-94eff555adce@github.com> Message-ID: On Wed, 27 Mar 2024 22:41:33 GMT, Pavel Rappo wrote: > Would this be the first lint -- not doclint -- warning related to comments, let alone doc comments? No. `-Xlint:dep-ann` correlates `@Deprecated` annotations with `@deprecated` tags in doc comments. > src/jdk.javadoc/share/man/javadoc.1 line 111: > >> 109: source code with the \f[V]javac\f[R] option \f[V]-Xlint\f[R], or more >> 110: specifically, \f[V]-Xlint:dangling-doc-comments\f[R]. >> 111: Within a source file, you may use suppress any warnings generated by > > Typo? > Suggestion: > > Within a source file, you may suppress any warnings generated by Thanks; I'll check the underlying original. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024162355 PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1542157047 From hgreule at openjdk.org Thu Mar 28 08:37:00 2024 From: hgreule at openjdk.org (Hannes Greule) Date: Thu, 28 Mar 2024 08:37:00 GMT Subject: RFR: 8328536: javac - crash on unknown type referenced in yield statement [v2] In-Reply-To: References: Message-ID: > Pasting e.g. > > I m(I i, int x) { > return switch (x) { > default -> i; > }; > } > > in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch. > > Javac will not crash but swallow the exception, and create a file containing the command line options. > > I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally. Hannes Greule 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 three additional commits since the last revision: - Merge branch 'refs/heads/master' into fix/switch-yield-unknown-type-crash - add bug id - Fix jshell crash on unknown type in switch yield ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18383/files - new: https://git.openjdk.org/jdk/pull/18383/files/ed7dc8fe..846ac70c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18383&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18383&range=00-01 Stats: 65016 lines in 2504 files changed: 13779 ins; 8799 del; 42438 mod Patch: https://git.openjdk.org/jdk/pull/18383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18383/head:pull/18383 PR: https://git.openjdk.org/jdk/pull/18383 From vromero at openjdk.org Fri Mar 29 03:07:32 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 29 Mar 2024 03:07:32 GMT Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote: > Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option. > > The work can be thought of as in 3 parts: > > 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not. > > 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The procedure for handling dangling doc comments is described in this comment in `JavacParser`. > > * Dangling documentation comments are handled as follows. > * 1. {@code Scanner} adds all doc comments to a queue of > * recent doc comments. The queue is flushed whenever > * it is known that the recent doc comments should be > * ignored and should not cause any warnings. > * 2. The primary documentation comment is the one obtained > * from the first token of any declaration. > * (using {@code token.getDocComment()}. > * 3. At the end of the "signature" of the declaration > * (that is, before any initialization or body for the > * declaration) any other "recent" comments are saved > * in a map using the primary comment as a key, > * using this method, {@code saveDanglingComments}. > * 4. When the tree node for the declaration is finally > * available, and the primary comment, if any, > * is "attached", (in {@link #attach}) any related > * dangling comments are also attached to the tree node > * by registering them using the {@link #deferredLintHandler}. > * 5. (Later) Warnings may be genereated for the dangling > * comments, subject to the {@code -Xlint} and > * {@code @SuppressWarnings}. > > > 3. Updates to the make files to disable the warnings in modules for which the > warning is generated. This is often because of the confusing use of `/**` to > create box or other standout comments. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-1967750057