Community
Participate
Working Groups
Currently jdt-core does not offer any way to get extended ranges of compilation unit AST nodes hierarchy. As now, we build and store comments table in compilation unit, it's possible to compute and give users acces to these extended ranges...
Fixed. Now users have getCommentList(), getExtendedStartPosition(ASTNode) and getExtendedLength(ASTNode) accessible on org.eclipse.jdt.core.dom.CompilationUnit. [jdt-core-internal] Implementation of CommentMapper heuristic done in org.eclipse.jdt.core.dom.DefaultCommentMapper. Note that Scanner has been modified to store only the text of line comments and not trailing '\r' and '\n' characters. This is internal table of Scanner which has been impacted but have a side on IMethod.getSourceRange() when the node has a trailing line comment as it will length 2 characters less... Test cases added in jdt.core.tests.dom.ASTConverterJavadocTest
Here are some additional information on this feature implementation... Unlike ASTNode#getStartPosition() and ASTNode#getLength() the extended source range may include comments and whitespace immediately before or after the normal source range for the node. The compilation unit will now store a instance of DefaultCommentMapper which will be initialized when the compilation unit is converted into DOM/AST nodes hierarchy (see ASTConverter.convert(CompilationUnitDeclaration, char[])). For each node of hierarchy, the comment mapper will look for leading and trailing comments. If some exist, then store their indexes (first and last) in corresponding tables. When user request extended range to compilation unit for a node, it requests it from its DefaultCommentMapper which searches in its tables possible leading and/or trailing comments. Returns start position of first leading comments for extended start position or node start position if no leading comments was found. Returns length including last trailing comments for extended length or node length if no trailing comments was found.
Here are also some details on the heuristic implemented in DefaultCommentMapper for leading and trailing comments.: 1) for leading comments, it searchs first comment before node start position. Then it goes up in comments list until one of the following condition is true: - comment is over previous end - there's other than white characters between current node and comment - there's more than 1 line between current node and comment If all these conditions are false, then found comment becomes current node and loop with previous comment. If at least one potential comment has been found, then no token should be on the same line before, so remove all comments which do not verify this assumption. If finally there is a subset of comments, then store start and end indexes in leading comments table. 2) for trailing comments, it searchs first comment after node end position. Then it goes down in comments list until one of the following condition is true: - comment is after next start - there's other than white characters between current node and comment - there's more than 1 line between current node and comment If all these conditions are false, then found comment becomes current node and loop with next comment. If at least one potential comment has been found, then last comment should be separated from next start line (ie. at least two lines after). If this is not the case then skip all comments which were not on the same line than the end of the node. If finally there is a subset of comments, then store start and end indexes in trailing comments table.
Verified in build I200403250800.
*** Bug 29178 has been marked as a duplicate of this bug. ***
