RFR: JDK-8242607 -Xdoclint doesn't report missing/unexpected comments

[Jonathan Gibbons]

Hi Kumar,

It's hard to use preview features in javac/javadoc because of the 
bootstrap N-1 problem,
but yes, DocCommentInfo could be a record; also Utils.Pair is only used 
in option decoding
for `-linkoffline` and could/should be moved there.

I'd also like the review the use of 3 separate maps to get doc comment 
info from elements:
there's one down in com.sun.source world, one in CommentUtils and 
another in Utils.

-- Jon


On 6/9/20 1:43 PM, Kumar Srinivasan wrote:
> Hi Jon,
>
> Looks good.
>
> Out of curiosity, is it worthwhile to replace DocCommentInfo with 
>  Record ?
>
> There may be other places where these Pair-like containers were 
> introduced in the doclet and javadoc tool.
>
> Kumar
>
>
>> On Jun 8, 2020, at 9:48 PM, Jonathan Gibbons 
>> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>> Please review a partial fix for this issue, which is about different 
>> doclint results
>> when invoking doclint from javac and javadoc.
>>
>> The reason for the partial fix is explained here:
>> https://bugs.openjdk.java.net/browse/JDK-8242607?focusedCommentId=14344614&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14344614
>>
>> Within the patch, the primary change is the restructuring of the 
>> if-statement at about line 2706
>> in Utils.java. Specifically, the call
>> 	configuration.workArounds.runDocLint(path);
>>
>> is moved outside of the test
>>
>> if (docCommentTree != null
>>
>> which is the root cause of the error.
>>
>> At the same time, the patch includes a minor cleanup to rename the 
>> `DocCommentDuo`
>> class to a slightly more abstract name `DocCommentInfo`. The old 
>> `DocCommentDuo`
>> inappropriately reflects some of the historical origins of the name. 
>> The change percolates
>> into some local variable names and member names as well.  I also 
>> tried to cleanup some
>> of the comments in this area, without changing functionality. The net 
>> result is a
>> perceived need for more cleanup, including functionality cleanup, in 
>> another changeset.
>>
>> -- Jon
>>
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242607
>> Webrev: http://cr.openjdk.java.net/~jjg/8242607/webrev.00/
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20200609/de92e80e/attachment-0001.htm>