RFR: JDK-8227923: End position of EndElementTree is -1
jonathan.gibbons at oracle.com
Fri Jul 19 14:38:48 UTC 2019
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
>> 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
Ah OK, thanks; I'd forgotten that!
>> -- Jon
>> On 07/18/2019 08:53 AM, Jan Lahoda wrote:
>>> 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
>>> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8227923/webrev.00/
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8227923
>>> How does this look?
More information about the compiler-dev