On Fri, 12 Jan 2024 15:55:43 GMT, Pavel Rappo <[email protected]> wrote:
>> 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 seven additional
>> commits since the last revision:
>>
>> - 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/source/doctree/RawTextTree.java line
> 40:
>
>> 38: * @apiNote
>> 39: * This class may be used to represent tree nodes containing
>> 40: * {@linkplain DocTree.Kind#MARKDOWN Markdown} text.
>
> This means that there is one-to-many relationship between `RawTextTree` and
> `DocTree.KIND`. This in turn perpetuates the pattern of checking the kind
> followed by casting as opposed to more modern `instanceof` pattern matching.
> There's nothing wrong with it per se, however I wonder what the rationale is
> for leaving this part of the API open-ended. Is it to support other types of
> raw text in the future?
Yes, the thinking was to allow it to be open-ended.
In this case, while I think we should specify the ability to use
`instanceof`-style checks with this API, I do not think it would be necessary
... there is no need for a subtype for `MarkdownTree`, nor would I expect there
to be one for any other kind of raw text.
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
> line 89:
>
>> 87: POSTAMBLE,
>> 88: /** The rich-text content of an inline documentation comment
>> tag. */
>> 89: INLINE
>
> Do we also need to say something about `.md` files here?
Probably, yes.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1454249356
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1454250904
