[cdt-core-dev] Bug in FileLocation.getEndingLineNumber()

["Manuel Woelker" <Woelker@xxxxxx>]

Hello everyone!

While trying to integrate the CDT core into an academic code analysis tool I
ran into a slight problem with the function
org.eclipse.cdt.internal.core.parser.scanner2.LocationMap.FileLocation.getEn
dingLineNumber().

If an AST Node goes right up to the end of the file, the CDT core resports
the ending linenumber incorrectly as 1. This is because getEndingLineNumber
does not report the line number of the last character of the node, but the
one following immediately after that. Normally this is not an issue, since
that character will still be on the same line. However, if there is no next
character
org.eclipse.cdt.internal.core.parser.scanner2.LocationMap._CompositeFileCont
ext.getLineNumber(int) returns 1

Proposed solution:
Change
org.eclipse.cdt.internal.core.parser.scanner2.LocationMap.FileLocation.getEn
dingLineNumber()
from
        public int getEndingLineNumber() {
            _CompositeFileContext i = getFileContext();
            if( i != null )
                return i.getLineNumber( getNodeOffset() + getNodeLength());
            return 0;
        }
To
        public int getEndingLineNumber() {
            _CompositeFileContext i = getFileContext();
            if( i != null )
                return i.getLineNumber( getNodeOffset() + getNodeLength() -
1);
            return 0;
        }
This returns the line of the last character of the node and thus works
correctly for nodes at the file end.

Apart from that, I would like to take the opportunity to tell CDT developers
that they are doing a great job. The CDT, and especially the new DOM package
are solid groundwork, making the development of this code analysis tool much
easier. Thanks for your effort!

Cheers
 - Manuel Woelker