RFR: JDK-8227923: End position of EndElementTree is -1

[Jonathan Gibbons]

Inline

On 7/19/19 7:28 AM, Jan Lahoda wrote:
> On 18. 07. 19 20:44, Jonathan Gibbons wrote:
>> The patch looks OK for the problem it is addressing, but it shows up 
>> a probably-unrelated bug in DocCommentParser.
>>
>> Look at these lines in 
>> http://cr.openjdk.java.net/~jlahoda/8227923/webrev.00/test/langtools/tools/javac/doctree/positions/TestPosition.out.sdiff.html:
>>
>> 94 TEXT:
>> 95 *
>> 96 *!trailing-whitespace!
>>
>> This seems to indicate that leading <space><asterisk> were not being 
>> skipped as they should be.  This needs to be looked at, but can be 
>> done separately from this fix.
>
> One thing to note is that the code snippets in the golden output are 
> not DocTree.toString() (which don't contain the <space><asterisk>), 
> but the part of the original code between the starting and ending 
> position. Which for trees that span multiple lines may include the 
> <space><asterisk>.
Ah OK, thanks; I'd forgotten that!
>
> Jan
>
>>
>> -- Jon
>>
>> On 07/18/2019 08:53 AM, Jan Lahoda wrote:
>>> Hi,
>>>
>>> The end position of some DocTrees (namely EndElementTree, EntityTree 
>>> and CommentTree) is reported as -1 from 
>>> DocTrees.getEndPosition(CompilationUnitTree, DocCommentTree, DocTree)
>>>
>>> For EntityTree and CommentTree, the end position can be currently 
>>> computed easily. For EndElementTree, the proposal is to record the 
>>> end position during parsing, as is done for the corresponding 
>>> StartElementTree.
>>>
>>> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8227923/webrev.00/
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8227923
>>>
>>> How does this look?
>>>
>>> Thanks,
>>>     Jan
>>