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

[Argyrios Kyrtzidis]

Committed in r216480, thank you!

> On Aug 23, 2014, at 4:19 AM, Craig Tenenbaum <zarathustra.zoroaster at gmail.com> wrote:
> 
> 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
> <D5041.12881.patch>