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

[Vicente Romero]

I see, thanks it is clearer to me now. I'm OK with the last version

Vicente

On 7/26/19 9:05 AM, Jan Lahoda wrote:
> 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
>>