> Please review a patch to add support for Markdown syntax in documentation
> comments, as described in the associated JEP.
>
> Notable features:
>
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java`
> libra
On Wed, 7 Feb 2024 00:16:57 GMT, Jonathan Gibbons wrote:
>> There are two cases that need consideration:
>> 1. A tree that is not modified during the transformation, as in the test
>> case here, so that all nodes should be "as before"
>> 2. A tree that is modified during the transformation, rais
On Tue, 6 Feb 2024 19:57:45 GMT, Jonathan Gibbons wrote:
>> Uugh. Noted.
>
> There are two cases that need consideration:
> 1. A tree that is not modified during the transformation, as in the test case
> here, so that all nodes should be "as before"
> 2. A tree that is modified during the trans
> Please review a patch to add support for Markdown syntax in documentation
> comments, as described in the associated JEP.
>
> Notable features:
>
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java`
> libra
> Please review a patch to add support for Markdown syntax in documentation
> comments, as described in the associated JEP.
>
> Notable features:
>
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java`
> libra
On Tue, 6 Feb 2024 19:27:55 GMT, Jonathan Gibbons wrote:
>> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java
>> line 1:
>>
>>> 1: /*
>>
>> This transformer seems to break positions of the `RawTextTree`.
>> For javadoc like:
>>
>> /// Mar
On Tue, 6 Feb 2024 07:08:13 GMT, Jan Lahoda wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> First pass at remove DocCommentTransformer from the public API.
>>
>> It is still declared internally, and instal
On Tue, 6 Feb 2024 17:29:25 GMT, Joe Darcy wrote:
>> src/java.base/share/classes/sun/net/www/MessageHeader.java line 53:
>>
>>> 51: }
>>> 52:
>>> 53: @SuppressWarnings("this-escape")
>>
>> An alternative here could be to make the class final. AFAICS it's not
>> subclassed anywhere. If
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Tue, 6 Feb 2024 16:53:37 GMT, Magnus Ihse Bursie wrote:
> Over time, we have been better at addressing inconsistencies in the build,
> but the exceptions put in place in compare.sh have not been updated to
> reflect this.
>
> This attempts to make sure we only keep those exceptions that are
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Tue, 6 Feb 2024 14:35:52 GMT, Daniel Fuchs wrote:
>> After the "this-escape" lint warning was added to javac (JDK-8015831), the
>> base module was not updated to be able to compile with this warning enabled.
>> This PR makes the necessary changes to allow the base module to build with
>> th
Over time, we have been better at addressing inconsistencies in the build, but
the exceptions put in place in compare.sh have not been updated to reflect this.
This attempts to make sure we only keep those exceptions that are currently
actually needed to verify a reproducible build (the primary
On Fri, 2 Feb 2024 07:01:33 GMT, Sam James wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also fix fstatvfs on AIX
>
> make/modules/jdk.hotspot.agent/Lib.gmk line 31:
>
>> 29:
>> 30: ifeq ($(call isTargetO
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Tue, 6 Feb 2024 08:20:39 GMT, Magnus Ihse Bursie wrote:
> I'd just hate to see all this work go to waste.
Same here!
-
PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1929780538
On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Sat, 3 Feb 2024 11:29:55 GMT, George Adams wrote:
> Now that macOS M1 executors are [available in GitHub
> actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/)
> it makes sense to move the build to run on M1 (rather t
On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on X8
On Sat, 3 Feb 2024 16:15:11 GMT, George Adams wrote:
> Noting that macos-14 is arm64 only in GitHub so such a change might not be
> useful in this scenario.
That's a shame, really. It would be good if we switched x64 to macos-14 as soon
as it is available, so we are on the same version.
-
On Sat, 3 Feb 2024 21:55:25 GMT, George Adams wrote:
>> Now that macOS M1 executors are [available in GitHub
>> actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/)
>> it makes sense to move the build to run on M1 (rathe
On Tue, 6 Feb 2024 02:28:32 GMT, Joe Darcy wrote:
> Add policy statement about lint warnings to various langtools modules.
LGTM
-
Marked as reviewed by ihse (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17718#pullrequestreview-1865030163
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Sat, 3 Feb 2024 10:07:26 GMT, Sam James wrote:
>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>>
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
>
Similarly to [JDK-8325163](https://bugs.openjdk.org/browse/JDK-8325163), this
enables pedantic mode for gcc, ensuring stricter Standard conformance and
allowing for buggy and broken code previously undetectable by gcc to be caught
-
Commit messages:
- Semicolon in compilerWarnings_
On Mon, 11 Dec 2023 18:25:09 GMT, Ludovic Henry wrote:
>> @theRealAph
>>> Or is there likely to be a plan to e.g. build Oracle's releases with SLEEF
>>> support?
>>
>> I can't say anything for sure, but I picked up some positive vibes from our
>> internal chat. I think the idea was that libsl
On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on X8
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Also
On Mon, 5 Feb 2024 14:06:21 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on X8
On Fri, 8 Dec 2023 00:50:59 GMT, Xiaohong Gong wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix potential attribute issue
>
>> Build changes finally look good. Great, actually! Thanks for persisting,
>> despit
On Mon, 5 Feb 2024 14:15:44 GMT, Matthias Baesken wrote:
>
> Thanks for the AIX related effort ; I put it again into our internal
> build/test queue.
With the latest commit the build again fails on AIX with this error
/jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27:
33 matches
Mail list logo
