RFR: JDK-8227922: DocTreeScanner does not dive into AttributeTree.getValue() and LiteralTree.getBody()

[Jan Lahoda]

On 22. 07. 19 18:55, Vicente Romero wrote:
> looks good, the only nit is that probably the text in the CSR section: 
> "Compatibility Risk" could be improved with a rephrasing. At least it is 
> not clear to me that if a class doesn't override, for example, 
> visitLiteral, how that method will be invoked at all? I think that you 
> mean that a visitLiteral implementation in a subclass will be invoked 
> with, possible, more literals than before?

Thanks Vicente. I tried to phrase it better in the CSR. It issue is that 
when there is e.g. "{@code something}" in the javadoc comment, using the 
DocTreeScanner before this patch didn't invoke the visitText method for 
"something", but after this patch, it will be called for that TextNode.

Jan

> 
> Thanks,
> Vicente
> 
> On 7/18/19 9:28 AM, Jan Lahoda wrote:
>> Hi,
>>
>> com.sun.source.util.DocTreeScanner#visitAttribute is not scanning over 
>> the children of AttributeNode (i.e. AttributeNode#getValue()), and 
>> DocTreeScanner#visitLiteral is not scanning over the children of 
>> LiteralNode (i.e. LiteralNode#getBody()). The proposal here is to fix 
>> DocTreeScanner to scan over the children of these two node types.
>>
>> Webrev: http://cr.openjdk.java.net/~jlahoda/8227922/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8227922
>>
>> As this change may cause new nodes to be encountered by subclasses of 
>> DocTreeScanner, with possibly undesirable effects (like in DocLint's 
>> Checker) and also affects the javadoc for the two methods, CSR appears 
>> to be needed as well, so I'd like to ask for a review of that as well:
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8228371
>>
>> How does this look?
>>
>> Thanks,
>>     Jan
>