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

[Jan Lahoda]

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>.

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
>