On Mon, 24 May 2021 21:05:02 GMT, Pavel Rappo wrote:
> When a method is said to be called "on an object", this means that the object
> is a receiver. When a method is said to be called "with an object", this
> means that the object is a parameter.
>
&g
; method is called on the instance
> of (Doc)TreeScanner with that instance of (Doc)Tree.
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Remove inconsistent whitespace in
-
Changes:
- all: https://git.ope
When a method is said to be called "on an object", this means that the object
is a receiver. When a method is said to be called "with an object", this means
that the object is a parameter.
To scan an instance of (Doc)Tree, the "scan" method is called on the instance
of (Doc)TreeScanner with
On Mon, 24 May 2021 18:49:08 GMT, Jonathan Gibbons wrote:
> mildly worrying that "make docs" did not give errors
This should be currently detectable by DocLint: since `` is consumed by
`@code`, the `ul` element is left unclosed.
-
PR: https://git.openjdk.java.net/jdk/pull/4074
On Mon, 24 May 2021 20:32:57 GMT, Jonathan Gibbons wrote:
>> Please review a change to overhaul the javadoc support for diagnostics to
>> better leverage the support available in javac. This includes the ability
>> for all javadoc diagnostics to show a "source line and caret" to indicate
>>
On Mon, 24 May 2021 14:51:52 GMT, Ian Graves wrote:
>> 8267329: Modernize Javadoc code to use instanceof with pattern matching
>
> Ian Graves 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 master
> -
On Wed, 19 May 2021 17:20:02 GMT, Jonathan Gibbons wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Name shortening. Copyright updates.
>
>
On Mon, 17 May 2021 20:40:18 GMT, Jonathan Gibbons wrote:
>> Please review a change to overhaul the javadoc support for diagnostics to
>> better leverage the support available in javac. This includes the ability
>> for all javadoc diagnostics to show a "source line and caret" to indicate
>>
On Tue, 18 May 2021 00:38:40 GMT, Jonathan Gibbons wrote:
> Please review a relatively simple update to expose the 1 or 2 streams
> available within javadoc for writing expected or diagnostic output.
>
> The change at this time is just to _expose_ the streams; followup work may
> change how
On Thu, 20 May 2021 15:19:43 GMT, Jonathan Gibbons wrote:
>> Please review a simple fix to treat `wbr` as a void element.
>
> Jonathan Gibbons has updated the pull request incrementally with one
> additional commit since the last revision:
>
> update test
Marked as reviewed by prappo
On Wed, 19 May 2021 18:58:17 GMT, Jonathan Gibbons wrote:
>> Please review a simple fix to treat `wbr` as a void element.
>
> Jonathan Gibbons has updated the pull request incrementally with one
> additional commit since the last revision:
>
> add test
On Wed, 19 May 2021 23:36:07 GMT, Jonathan Gibbons wrote:
> Please review a trivial patch to remote an unused internal interface and its
> implementation.
>
> I've looked as far back as JDK 8, and the code was unused even back then.
Marked as reviewed by prappo (Reviewer).
-
PR:
On Thu, 20 May 2021 13:20:01 GMT, Pavel Rappo wrote:
>> The documentation header is a standard langtools warnings to all those
>> people that rely on access to javac and javadoc internals.
>>
>> Class not used ... wow, correct. I'll file an RFE to investigate and remov
On Wed, 19 May 2021 22:04:14 GMT, Jonathan Gibbons wrote:
>> My first reaction is in agreement, but upon further inspection it seems that
>> this class is not used by anything in the module. Interestingly its
>> documentation header warns not to rely on its behavior to remain the same.
>
> The
On Wed, 19 May 2021 23:36:07 GMT, Jonathan Gibbons wrote:
> Please review a trivial patch to remote an unused internal interface and its
> implementation.
>
> I've looked as far back as JDK 8, and the code was unused even back then.
This might be familiar:
On Wed, 19 May 2021 10:43:29 GMT, liach
wrote:
>> This change fixes when a method body has only inline tags that produce no
>> output, the method summary will get eaten.
>>
>> This change allows `{@inheritDoc}` from empty parents to go through the code
>> path used by `-nocomment` and
On Wed, 19 May 2021 16:57:04 GMT, Ian Graves wrote:
>> 8267329: Modernize Javadoc code to use instanceof with pattern matching
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Name shortening. Copyright updates.
Although I
On Wed, 19 May 2021 16:03:19 GMT, Hannes Wallnöfer wrote:
>> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the
>> wrong message "')' missing in reference". That error message is not used
>> when the right parenthesis is missing, but when it occurs before the end of
>>
On Tue, 18 May 2021 23:41:47 GMT, Jonathan Gibbons wrote:
> 1. Reporter says nothing about streams. javadoc is inconsistent with javac
> and when run with two streams, it sends warnings and errors to one stream and
> notes to the other. javac now sends all diagnostics to the error stream,
>
On Wed, 19 May 2021 11:05:06 GMT, Hannes Wallnöfer wrote:
>> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the
>> wrong message "')' missing in reference". That error message is not used
>> when the right parenthesis is missing, but when it occurs before the end of
>>
On Wed, 19 May 2021 11:27:39 GMT, Hannes Wallnöfer wrote:
>> I looked at the usages of `isValid`; all of them are guarding the calls to
>> `HtmlTree.add`, in `SerialFieldWriter`, `TagletWriter`, and `HtmlTree.add`
>> itself. Hence, if a content builder has both valid and invalid parts, I
>>
On Wed, 19 May 2021 04:03:03 GMT, Ian Graves wrote:
>> 8267329: Modernize Javadoc code to use instanceof with pattern matching
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Typos
Ian, thanks for doing this carefully and
On Tue, 18 May 2021 15:36:26 GMT, liach
wrote:
>> This change fixes when a method body has only inline tags that produce no
>> output, the method summary will get eaten.
>>
>> This change allows `{@inheritDoc}` from empty parents to go through the code
>> path used by `-nocomment` and
On Tue, 18 May 2021 23:48:14 GMT, Jonathan Gibbons wrote:
> I'm not sure I completely understand your question.
I would like to have a mechanism to guard us from inconsistencies like this, is
all. Consider adding something like the below white-box test.
Test
import
On Wed, 19 May 2021 00:00:15 GMT, Jonathan Gibbons wrote:
>> Please review a trivial fix to avoid creating an unnecessary
>> `BufferedWriter`.
>>
>> `noreg-trivial` (or `noreg-cleanup` : take your pick). Either way, no test.
>
> Jonathan Gibbons has updated the pull request incrementally with
On Tue, 18 May 2021 17:15:56 GMT, Jonathan Gibbons wrote:
> Please review a simple fix to treat `war` as a void element.
I wonder if we could teach JavaDoc types that model HTML that void elements do
not require end tags. Before this change, WBR required an end tag despite being
void:
On Tue, 18 May 2021 16:22:56 GMT, liach
wrote:
> For this change, in fact, you can pretty much discard all previous change;
> the current commit is not related to the previous commit contents, as the way
> of approach and the test both got rewritten.
Yet, it is preferable to have preceding
On Tue, 18 May 2021 15:36:26 GMT, liach
wrote:
>> This change fixes when a method body has only inline tags that produce no
>> output, the method summary will get eaten.
>>
>> This change allows `{@inheritDoc}` from empty parents to go through the code
>> path used by `-nocomment` and
On Mon, 17 May 2021 20:40:18 GMT, Jonathan Gibbons wrote:
>> Please review a change to overhaul the javadoc support for diagnostics to
>> better leverage the support available in javac. This includes the ability
>> for all javadoc diagnostics to show a "source line and caret" to indicate
>>
On Tue, 18 May 2021 00:38:40 GMT, Jonathan Gibbons wrote:
> Please review a relatively simple update to expose the 1 or 2 streams
> available within javadoc for writing expected or diagnostic output.
>
> The change at this time is just to _expose_ the streams; followup work may
> change how
On Tue, 18 May 2021 04:33:52 GMT, Jonathan Gibbons wrote:
> Please review a trivial fix to avoid creating an unnecessary `BufferedWriter`.
>
> `noreg-trivial` (or `noreg-cleanup` : take your pick). Either way, no test.
Changes requested by prappo (Reviewer).
On Tue, 18 May 2021 01:42:57 GMT, liach
wrote:
> if an empty content stays empty, it's handled like htmltree.empty in a
> special case (just like what happens to nocomment) and included in table
> output. if it's wrapped in a div class=block, the check will not be triggered
> as it's not
On Tue, 18 May 2021 06:56:51 GMT, Hannes Wallnöfer wrote:
> Yes, you can look at it both ways, either there is a closing parenthesis
> where it shouldn't be, or there is text following a correctly placed closing
> parenthesis. We tend to see one or the other depending on whether the text up
>
On Mon, 17 May 2021 17:39:19 GMT, liach
wrote:
>> This change fixes when a method body has only inline tags that produce no
>> output, the method summary will get eaten.
>>
>> This change allows `{@inheritDoc}` from empty parents to go through the code
>> path used by `-nocomment` and
On Mon, 17 May 2021 16:54:07 GMT, Hannes Wallnöfer wrote:
> The primary problem was that key `compiler.err.dc.ref.bad.parens` had the
> wrong message "')' missing in reference". That error message is not used when
> the right parenthesis is missing, but when it occurs before the end of the
>
On Mon, 17 May 2021 09:30:17 GMT, Hannes Wallnöfer wrote:
> Trivial change to remove unused method.
Marked as reviewed by prappo (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/4049
On Mon, 17 May 2021 10:10:38 GMT, Hannes Wallnöfer wrote:
> Simple change to disable platform links in TestMemberSummary.java tests.
The change looks good. That said, should we be concerned about proliferation of
`--no-platform-links` in tests?
-
Marked as reviewed by prappo
On Mon, 10 May 2021 13:44:50 GMT, Hannes Wallnöfer wrote:
> Trivial change to fix value of `for` attribute in javadoc search label.
Marked as reviewed by prappo (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3949
On Mon, 10 May 2021 20:17:03 GMT, Hannes Wallnöfer wrote:
> I’d rather not. I don’t think it’s a huge improvement, there’s only 4 usages
> of this tag, and … it’s late and I’d like to close the issue :) I think there
> are some elements that are much more often used that don’t have a factory
On Mon, 10 May 2021 13:44:50 GMT, Hannes Wallnöfer wrote:
> Trivial change to fix value of `for` attribute in javadoc search label.
I wonder if a more robust fix would be to associate these elements by nesting
rather than by id:
-
PR:
On Mon, 10 May 2021 19:10:15 GMT, Jonathan Gibbons wrote:
> Please review a change for JavaDoc, for the Standard Doclet to copy legal
> header files into the generated docs from a default or designated directory.
On Mon, 10 May 2021 14:01:46 GMT, Hannes Wallnöfer wrote:
>> This replaces usages of the zero-width space character (ZWSP, entity
>> ``) with the HTML5 `` element. `` acts as a word break
>> opportunity without adding characters to the text content like ZWSP does. It
>> is supported in all
On Mon, 10 May 2021 13:44:50 GMT, Hannes Wallnöfer wrote:
> Trivial change to fix value of `for` attribute in javadoc search label.
What was that label's intended effect? I'm looking at the API documentation for
JDK 16 and that of the mainline and cannot seem to spot any visual difference.
On Mon, 10 May 2021 14:01:46 GMT, Hannes Wallnöfer wrote:
>> This replaces usages of the zero-width space character (ZWSP, entity
>> ``) with the HTML5 `` element. `` acts as a word break
>> opportunity without adding characters to the text content like ZWSP does. It
>> is supported in all
On Wed, 5 May 2021 13:55:10 GMT, Hannes Wallnöfer wrote:
>> This changes reference parsing in `DocCommentParser` to normalize whitespace
>> in signatures to a large extent. In particular, multiple whitespace
>> characters are coalesced into a single space character, and whitespace after
>>
On Wed, 5 May 2021 06:39:14 GMT, Hannes Wallnöfer wrote:
> `DocCommentParser#reference` only accepts whitespace within matching `()` or
> `<>`. A whitespace character before the parentheses as shown above will
> result in `java.net.URL#URL` being considered the reference and the part in
>
On Wed, 5 May 2021 07:40:25 GMT, Hannes Wallnöfer wrote:
>> This changes reference parsing in `DocCommentParser` to normalize whitespace
>> in signatures to a large extent. In particular, multiple whitespace
>> characters are coalesced into a single space character, and whitespace after
>>
Thanks for relaying that Twitter discussion. Although we've surveyed multiple
systems before agreeing on the snippet markup syntax that satisfies the needs
of our initial use case, OpenJDK, it is possible that we've missed some
important features.
What are the important features of AsciiDoc's
On Mon, 3 May 2021 17:52:12 GMT, Hannes Wallnöfer wrote:
>> This changes reference parsing in `DocCommentParser` to normalize whitespace
>> in signatures to a large extent. In particular, multiple whitespace
>> characters are coalesced into a single space character, and whitespace after
>>
On Wed, 28 Apr 2021 07:47:23 GMT, Hannes Wallnöfer wrote:
> This changes reference parsing in `DocCommentParser` to normalize whitespace
> in signatures to a large extent. In particular, multiple whitespace
> characters are coalesced into a single space character, and whitespace after
>
On Sat, 24 Apr 2021 01:17:51 GMT, Ian Graves wrote:
>> 8261168: Convert javadoc tool to use Stream.toList()
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Replacing one additional Collections.toList() with an explicit
>
On Thu, 22 Apr 2021 04:19:50 GMT, Ian Graves wrote:
>> 8261168: Convert javadoc tool to use Stream.toList()
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Changing Collectors.toList() to an explicit ArrayList collection
On Fri, 2 Apr 2021 17:37:21 GMT, Jonathan Gibbons wrote:
> Please review some minor updates to internal doc comments on javadoc code.
>
> In addition, since this is just a cleanup PR, some redundant modifiers noted
> by an IDE have been removed.
Looks good.
On Mon, 29 Mar 2021 16:06:31 GMT, Jonathan Gibbons wrote:
>> test/langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java line
>> 110:
>>
>>> 108: } catch (UnknownHostException e) {
>>> 109: out.println("Setup failed (" + testURLHost + " not found);
>>> this
On Wed, 24 Mar 2021 16:19:53 GMT, Jonathan Gibbons wrote:
>> Please review a trivial change to fix this test when run behind a firewall
>> with a proxy set.
>>
>> Previously, the test used `InetAddress.getLocalHost` which returns an IP
>> address for the current host. It runs a temporary
On Mon, 22 Mar 2021 22:26:08 GMT, Jonathan Gibbons wrote:
> Please review a trivial change to fix this test when run behind a firewall
> with a proxy set.
>
> Previously, the test used `InetAddress.getLocalHost` which returns an IP
> address for the current host. It runs a temporary local
On Tue, 16 Mar 2021 05:23:31 GMT, Jonathan Gibbons wrote:
> > I think we should consider alternative routes of improving performance. For
> > instance, could NIO both speed up I/O and simplify code?
>
> I don't understand the NIO comment. Under the covers, JavaFileManager uses
> NIO and has
On Mon, 15 Mar 2021 14:43:34 GMT, Hannes Wallnöfer wrote:
> the benefits quite solid, and the problems not unsurmountable
I wouldn't call the benefits I saw on my personal machine solid. But then
again, I'm not sure how to properly benchmark and evaluate results of that
benchmarking for a
On Fri, 5 Mar 2021 17:46:28 GMT, Jonathan Gibbons wrote:
>> Please review a new test to verify that the output of block tags is
>> generated in the expected order.
>>
>> The code in the standard doclet to generate the output is the same for all
>> use sites (modules, packages, class, members)
On Thu, 4 Mar 2021 22:42:43 GMT, Jonathan Gibbons wrote:
> Please review a tiny change to move a small utility method from a superclass
> into the one subclass where it is actually used.
Looks good.
-
Marked as reviewed by prappo (Reviewer).
PR:
On Fri, 5 Mar 2021 15:55:03 GMT, Jonathan Gibbons wrote:
>> test/langtools/jdk/javadoc/doclet/testTagOrder/TestTagOrder.java line 76:
>>
>>> 74: * @throws IllegalArgumentException well, never
>>> 75: * @since 1.0
>>> 76:
On Thu, 4 Mar 2021 21:12:15 GMT, Jonathan Gibbons wrote:
> Please review a new test to verify that the output of block tags is generated
> in the expected order.
>
> The code in the standard doclet to generate the output is the same for all
> use sites (modules, packages, class, members) and
On Thu, 4 Mar 2021 23:01:02 GMT, Jonathan Gibbons wrote:
>> Please review a fix to improve the handling of the legacy `@exception` tag.
>>
>> A patch for this was [previously
>> submitted](https://mail.openjdk.java.net/pipermail/javadoc-dev/2019-September/001139.html).
>> However, that patch
On Thu, 4 Mar 2021 15:47:25 GMT, Jonathan Gibbons wrote:
> > This commit changes the order of block tags in the output. The fact that no
> > tests failed when I ran them surprised me. I think we should both fix that
> > order and introduce a test for it.
>
> Can you give more details? Did you
On Wed, 3 Mar 2021 22:22:29 GMT, Jonathan Gibbons wrote:
> Please review a fix to improve the handling of the legacy `@exception` tag.
>
> A patch for this was [previously
> submitted](https://mail.openjdk.java.net/pipermail/javadoc-dev/2019-September/001139.html).
> However, that patch
On Mon, 22 Feb 2021 17:56:25 GMT, Jonathan Gibbons wrote:
> there is very little change in the utilization of the background writer as a
> function of the question size
Did you mean "queue size"? If so, then I also noticed that in my observation
no. 2 under the results table here:
On Mon, 22 Feb 2021 17:48:37 GMT, Jonathan Gibbons wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/BackgroundWriter.java
>> line 165:
>>
>>> 163: try {
>>> 164: executor.shutdown();
>>> 165: executor.awaitTermination(5,
On Mon, 22 Feb 2021 13:36:00 GMT, Pavel Rappo wrote:
>> This change is on the right track.
>>
>> 1. Although I'm not sure how "utilization" translates to a similar
>> measurement obtained through a profiling tool, I do think we can use
>> "utiliza
On Mon, 22 Feb 2021 13:03:04 GMT, Pavel Rappo wrote:
>> The standard doclet works by creating `HtmlDocument` objects and then
>> writing them out. Writing them can be safely done on a separate thread, and
>> doing so results in about an 8% speedup, by overlapping
On Sun, 21 Feb 2021 18:11:06 GMT, Jonathan Gibbons wrote:
> The standard doclet works by creating `HtmlDocument` objects and then writing
> them out. Writing them can be safely done on a separate thread, and doing so
> results in about an 8% speedup, by overlapping the write/IO time with the
On Fri, 5 Feb 2021 04:44:07 GMT, Jonathan Gibbons wrote:
>> Please review an update to improve the support, where appropriate, for
>> nested inline tags.
>>
>> It has always been the case that certain inline tags allow text and HTML to
>> appear within them. With tags like `{@return}` and
On Wed, 3 Feb 2021 04:28:21 GMT, Jonathan Gibbons wrote:
> Please review an update to improve the support, where appropriate, for nested
> inline tags.
>
> It has always been the case that certain inline tags allow text and HTML to
> appear within them. With tags like `{@return}` and
Resending my recent email in plain text; apologies for sending it previously in
rich text.
***
Dmitry,
8201533 is a Draft JEP for a feature that is currently under active
development. As such, that draft is prone to inconsistencies, inaccuracies,
typos, etc. As we further develop the feature
Dmitry,
8201533 is a Draft JEP for a feature that is currently under active
development. As such, that draft is prone to inconsistencies, inaccuracies,
typos, etc. As we further develop the feature and receive feedback on it, that
draft will improve and eventually reach the high bar of JEP
# Snippet Markup
One of the major challenges of the "Snippets" project is to design markup.
Although we've made good progress there, we are still exploring the respective
design space. This note provides some background and summarizes the current
state of that exploration at a very high level.
Roger,
I'd add to what Jon has already said about indentation. Early on in our
prototype we recognized the need for clear rules and convenient control for
indentation. We knew that having those would allow "Snippets" to improve on the
solution provided by the "pre-code" compound:
{@code
On Tue, 8 Dec 2020 21:10:56 GMT, Jonathan Gibbons wrote:
>> This change extends the functionality of the `@return` tag so that it can
>> also be used as an inline tag in the first sentence of a description.
>>
>> The goal is to be able to simplify the following common pattern:
>>
>> /**
On Tue, 8 Dec 2020 19:27:32 GMT, Jonathan Gibbons wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ReturnTaglet.java
>> line 76:
>>
>>> 74: } else {
>>> 75: List firstSentence =
>>> utils.getFirstSentenceTrees(input.element);
>>> 76:
On Wed, 2 Dec 2020 15:39:56 GMT, Roger Riggs wrote:
>> @RogerRiggs ,
>>
>> 1. I agree on that the lack of `.` after `}` looks unnatural:
>>
>> /**
>> * {@return the result} Optional additional text.
>> */
>> int method() {
>>
>> 2. I disagree on allowing a flexible expansion. This
On Fri, 27 Nov 2020 16:33:27 GMT, Roger Riggs wrote:
>> This change extends the functionality of the `@return` tag so that it can
>> also be used as an inline tag in the first sentence of a description.
>>
>> The goal is to be able to simplify the following common pattern:
>>
>> /**
>>
gt; The way I read the code changes, you need to find examples of classes with
> the same name but in different packages. The example that came to mind for
> me is `ToolProvider`.
>
> -- Jon
>
> On 11/26/20 8:51 AM, Pavel Rappo wrote:
>> On Fri, 20 Nov 2020
On Thu, 26 Nov 2020 16:54:06 GMT, Hannes Wallnöfer wrote:
>> This is a simple change to throw jtreg.SkippedException if no JavaScript
>> engine is available to run the TestSearchScript test. In my previous attempt
>> I tried to use the SkippedException class already present elsewhere in the
On Fri, 20 Nov 2020 15:00:56 GMT, Hannes Wallnöfer wrote:
> This PR softens the case-sensitivity rules in Javadoc searches by including
> results of case-insensitive search if a case-sensitive yields no or very few
> results.
>
> Changes also include some restructuring of the search.js code
On Tue, 24 Nov 2020 15:08:27 GMT, Hannes Wallnöfer wrote:
> This is a simple change to throw jtreg.SkippedException if no JavaScript
> engine is available to run the TestSearchScript test. In my previous attempt
> I tried to use the SkippedException class already present elsewhere in the
>
On Wed, 4 Nov 2020 20:57:06 GMT, Jonathan Gibbons wrote:
>> This introduces support for a new `@spec` tag that can be used as either an
>> inline tag or as a block tag. It is used to identify references to external
>> specifications, in such a way that the references can be collected together
On Wed, 4 Nov 2020 20:57:06 GMT, Jonathan Gibbons wrote:
>> This introduces support for a new `@spec` tag that can be used as either an
>> inline tag or as a block tag. It is used to identify references to external
>> specifications, in such a way that the references can be collected together
On Wed, 30 Sep 2020 18:40:14 GMT, Jonathan Gibbons wrote:
>> This is a general cleanup of various classes related to the handling of tags
>> and taglets in the standard doclet.
>>
>> The initial motivation was to clean up static methods on `TagletWriter` that
>> took a `TagletWriter` as a
On Wed, 30 Sep 2020 17:11:19 GMT, Jonathan Gibbons wrote:
>> This is a general cleanup of various classes related to the handling of tags
>> and taglets in the standard doclet.
>>
>> The initial motivation was to clean up static methods on `TagletWriter` that
>> took a `TagletWriter` as a
On Tue, 29 Sep 2020 16:42:09 GMT, Jonathan Gibbons wrote:
> This is a general cleanup of various classes related to the handling of tags
> and taglets in the standard doclet.
>
> The initial motivation was to clean up static methods on `TagletWriter` that
> took a `TagletWriter` as a
On Tue, 29 Sep 2020 16:42:09 GMT, Jonathan Gibbons wrote:
> This is a general cleanup of various classes related to the handling of tags
> and taglets in the standard doclet.
>
> The initial motivation was to clean up static methods on `TagletWriter` that
> took a `TagletWriter` as a
On Tue, 29 Sep 2020 16:42:09 GMT, Jonathan Gibbons wrote:
> This is a general cleanup of various classes related to the handling of tags
> and taglets in the standard doclet.
>
> The initial motivation was to clean up static methods on `TagletWriter` that
> took a `TagletWriter` as a
On Tue, 29 Sep 2020 16:42:09 GMT, Jonathan Gibbons wrote:
> This is a general cleanup of various classes related to the handling of tags
> and taglets in the standard doclet.
>
> The initial motivation was to clean up static methods on `TagletWriter` that
> took a `TagletWriter` as a
On Wed, 30 Sep 2020 08:08:32 GMT, Pavel Rappo wrote:
>> The link for the `throws` type was not filtering out the bounds. A new
>> `LinkInfoImpl.Kind` is added for `THROWS_TYPE`.
>>
>> The loop to generate the list of exceptions is simplified.
>>
>> A new
On Tue, 29 Sep 2020 23:47:37 GMT, Jonathan Gibbons wrote:
> The link for the `throws` type was not filtering out the bounds. A new
> `LinkInfoImpl.Kind` is added for `THROWS_TYPE`.
>
> The loop to generate the list of exceptions is simplified.
>
> A new test is provided. The generated API for
On Tue, 29 Sep 2020 23:47:37 GMT, Jonathan Gibbons wrote:
> The link for the `throws` type was not filtering out the bounds. A new
> `LinkInfoImpl.Kind` is added for `THROWS_TYPE`.
>
> The loop to generate the list of exceptions is simplified.
>
> A new test is provided. The generated API for
On Mon, 14 Sep 2020 09:09:11 GMT, Pavel Rappo wrote:
> Yet another cleanup change that has accumulated during my work on
> `DocCommentParser` and other javadoc-related areas of
> compiler.
This pull request has now been integrated.
Changeset: e6a493ab
Author: Pavel Rappo
URL:
> Yet another cleanup change that has accumulated during my work on
> `DocCommentParser` and other javadoc-related areas of
> compiler.
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
To address pull-request feedback, I
On Mon, 14 Sep 2020 13:47:28 GMT, Vicente Romero wrote:
>> Yet another cleanup change that has accumulated during my work on
>> `DocCommentParser` and other javadoc-related areas of
>> compiler.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
> line 290:
>
Yet another cleanup change that has accumulated during my work on
`DocCommentParser` and other javadoc-related areas of
compiler.
-
Commit messages:
- Misc. cleanup
- Fixed an embarrassing typo in `{@docroot}`. (Yes, I know that "{@docroot}"
is case-insensitive when passed on a
On Fri, 11 Sep 2020 03:02:36 GMT, Jonathan Gibbons wrote:
>> A new method is added to the `DocTrees` utility class to return the
>> characters represented by a named or numeric
>> entity, as represented in an `EntityTree`.
>
> Jonathan Gibbons has updated the pull request incrementally with one
401 - 500 of 618 matches
Mail list logo
