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. 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.