Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]
On Fri, 19 Jan 2024 18:37:48 GMT, Jonathan Gibbons wrote:
>> 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`
>> library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains eight commits:
>
> - Merge with upstream/master
> - Merge with upstream/master
> - Merge remote-tracking branch 'upstream/master' into
> 8298405.doclet-markdown-v3
> - Address review comments
> - Fix whitespace
> - Improve handling of embedded inline taglets
> - Customize support for Markdown headings
> - JDK-8298405: Support Markdown in Documentation Comments
src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
line 271:
> 269: //if (textStart == -1) {
> 270: //textStart = bp;
> 271: //}
What's up with that?
src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
line 1333:
> 1331: lineKind = (ch == '\n' || ch == '\r') ?
> LineKind.BLANK
> 1332: : (indent <= 3) ? peekLineKind()
> 1333: : LineKind.OTHER;
Nested ternary-s are hard to read. Nested if-s are bulky. Sigh.
src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
line 1377:
> 1375: * @see href="https://spec.commonmark.org/0.30/#atx-headings;>ATX Headings
> 1376: */
> 1377: ATX_HEADER(Pattern.compile("#{1,6}( .*|$)")),
Actually, I wonder how accurate those regexes should match spec. Given the
definition [^*] of an ATX header and the fact that we always match the complete
(not find inside) a line, which by definition should not have line terminators,
shouldn't it be like this?
#{1,6}([ \t]+.*)?
[^*]: The opening sequence of # characters must be followed by spaces or tabs,
or by the end of line.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1462039425
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1462213698
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1462148038
Re: RFR: 8318696: Do not use LFS64 symbols on Linux [v5]
On Fri, 19 Jan 2024 23:50:46 GMT, Sam James wrote: >> The LFS64 symbols provided by glibc are not part of any standard and were >> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5). >> This commit replaces the usage of LFS64 symbols with their regular >> counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions >> will always act as their -64 variants on glibc. > > Sam James 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 master > - crank copyright > - sendfile64 -> sendfile > >Signed-off-by: Sam James > - buf64->buf > >Signed-off-by: Sam James > - Add message for assert > >Not all C++ stds implement it w/o. > - Add off_t static_asserts > >Signed-off-by: Sam James > - Do not use LFS64 symbols on Linux > >The LFS64 symbols provided by glibc are not part of any standard and >were gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in >1.2.5). This commit replaces the usage of LFS64 symbols with their >regular counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that > functions >will always act as their -64 variants on glibc. > >Signed-off-by: Sam James Could someone run the other commands again for older branches for me as well? I don't have access. - PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1903889096
Re: RFR: 8318696: Do not use LFS64 symbols on Linux [v5]
On Fri, 19 Jan 2024 23:50:46 GMT, Sam James wrote: >> The LFS64 symbols provided by glibc are not part of any standard and were >> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5). >> This commit replaces the usage of LFS64 symbols with their regular >> counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions >> will always act as their -64 variants on glibc. > > Sam James 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 master > - crank copyright > - sendfile64 -> sendfile > >Signed-off-by: Sam James > - buf64->buf > >Signed-off-by: Sam James > - Add message for assert > >Not all C++ stds implement it w/o. > - Add off_t static_asserts > >Signed-off-by: Sam James > - Do not use LFS64 symbols on Linux > >The LFS64 symbols provided by glibc are not part of any standard and >were gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in >1.2.5). This commit replaces the usage of LFS64 symbols with their >regular counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that > functions >will always act as their -64 variants on glibc. > >Signed-off-by: Sam James Backport to 21u should also be done - PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1903677564
