[PATCH] Fix for clang_Cursor_getSpellingNameRange() reportage of C++ functions

[Craig Tenenbaum]

Hi akyrtzi,

Currently, there is a minor defect in the source range reported by libclang's `clang_Cursor_getSpellingNameRange()` function such that destructor spellings are reported to only be one character wide (hence, only covering the leading '`~`' tilde), and only covers the initial '`operator`' segment of any overloaded operator. Currently, the kdev-clang plugin for the KDevelop IDE uses this function to aid in syntax highlighting, so these shortfalls result in erroneous highlighting. The issue obviously seemed to be a lexical one, the transition from one token-type to another seemed to be tripping things up, and after a sense, this is, indeed, what's going wrong, but not quite. In attempting to trace the origin of the problem, I discovered that the C++ interface to the AST doesn't have this issue despite depending on the same tokenization constructs (as far as I could tell, anyway). Rather, the default approach libclang uses breaks on a single token type; in line with the special treatment given to some ObjC constructs, I felt this problem would be best handled by special-casing destructor, C++ method, and C++ conversion function cursors (more on that later) depending on the underlying C++ logic as the ObjC cases do.

Additionally, in the process of writing regression tests and testing the patch, I also discovered that C++ conversion functions were having the same issue as destructors and operator overloads.

http://reviews.llvm.org/D5041

Files:
  test/Index/get-cursor.cpp
  tools/libclang/CIndex.cpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D5041.12881.patch
Type: text/x-patch
Size: 9571 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140823/aa7b47cc/attachment.bin>