D7799: Type Alias Template fix

[Craig Tenenbaum]

craigt created this revision.

REVISION SUMMARY
  Since Clang 3.8, libclang began exposing an `CXCursor_TypeAliasTemplateDecl` cursor as a result of work done by a KDevelop developer. Ironically, this feature was never actually integrated into KDevelop's clang support, and because of how cursors are dispatched in clang's DUChain builder, the default action is to recurse into any cursor enumeration not explicitly listed. This, in turn, recurses into `CXCursor_TypeAliasTemplateDecl`, and while that does eventually pick up a child `CXCursor_TypeAliasDecl` cursor, ensuring that the declaration is added to the DUChain, the foremost descendants of `CXCursor_TypeAliasTemplateDecl` tend to be template parameters, effectively leaking these parameters into the surrounding context.
  
  Moreover, since the addition of `CXCursorTypeAliasTemplateDecl`, references from `CXCursor_TemplateRef` point directly to these cursors which, unfortunately, have a spelling range which covers the `using` keyword that introduces the name which will refer to this alias, but not the name itself. Additionally, unlike `typedef` cursors or `CXCursor_TypeAliasDecl`, `CXCursor_TypeAliasTemplateDecl` yields no useful information about the type it is aliasing; interestingly, `CXCursor_TypeAliasDecl` provides this information without fault, even if it refers to templates with template parameters. Ultimately, this means that the actual `CXCursor_TypeAliasTemplateDecl` cursor, for the moment, is good for little more than signalling the beginning of a new context to capture template parameters and possibly new types, and the actual, declarative unit is still a `CXCursor_TypeAliasDecl` cursor. Sadly, this means the procedure for building uses from cursors needs to be tweaked so lookups will make the correct association. Ultimately, the real fix should be in investigating the upstream implementation of `CXCursor_TypeAliasTemplateDecl` to see if it can be made to function more like a traditional declaration cursor.
  
  BUG: 384580
  FIXED-IN: 5.2

TEST PLAN
  I ran the entire test suite before and after my changes and noticed no new breakage. Maybe I should add a //gotcha// test-case for the leaked parameters?

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D7799

AFFECTED FILES
  plugins/clang/duchain/builder.cpp

To: craigt, #kdevelop, mwolff, kfunk
Cc: kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20170913/75699e41/attachment.html>