Different CXCursor objects when traversing AST than when getting from location.


Bugzilla Link	PR11679
Status	NEW
Importance	P normal
Reported by	Manuel Holtgrewe (manuel.holtgrewe@fu-berlin.de)
Reported on	2011-12-30 11:24:34 -0800
Last modified on	2011-12-30 11:24:34 -0800
Version	trunk
Hardware	PC Linux
CC
Fixed by commit(s)
Attachments	`libclang_cursor_test.diff` (2199 bytes, text/plain)
Blocks
Blocked by
See also

Created attachment 7820
Diff to python bindings tests for libclang that expose the error.

The attached diff to the Python bindings exposes a problem with the libclang
Python bindings or the underlying libclang.so library. (I assume that the
problem comes from the libclang.so binary).

The problem occurs with children of do/while statements below compound
statements and is as follows:

First, retrieve a CXCursor instance C1 from Python by iterating the AST tree.
Then, retrieve another one C2 directly by the source location. Both have the
same kind and the same extent. However, when compared through the
clang_equalCursors(), they differ.

I looked into the implementation of operator==() for CXCursor, and here, the
kind and the data members are compared. The diff to the tests also print the
output and apparently the value of data[0] is wrong (reported as None) when
traversing the AST.

The problem appears with 3.0 and the current trunk version.

The nosetests output is given below.

$ nosetests --nocapture
CursorKind.DO_STMT
CursorKind.DO_STMT
<SourceRange start <SourceLocation file 't.c', line 24, column 5>, end
<SourceLocation file 't.c', line 26, column 20>>
<SourceRange start <SourceLocation file 't.c', line 24, column 5>, end
<SourceLocation file 't.c', line 26, column 20>>
None
34759552
34760136
34760136
31756192
31756192
..................int x;
....
----------------------------------------------------------------------
Ran 22 tests in 0.165s

OK

Quuxplusone / LLVMBugzillaTest

Different CXCursor objects when traversing AST than when getting from location. #10639