<table><tr><td style="">craigt created this revision.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D7799" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>Since Clang 3.8, libclang began exposing an <tt style="background: #ebebeb; font-size: 13px;">CXCursor_TypeAliasTemplateDecl</tt> 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 <tt style="background: #ebebeb; font-size: 13px;">CXCursor_TypeAliasTemplateDecl</tt>, and while that does eventually pick up a child <tt style="background: #ebebeb; font-size: 13px;">CXCursor_TypeAliasDecl</tt> cursor, ensuring that the declaration is added to the DUChain, the foremost descendants of <tt style="background: #ebebeb; font-size: 13px;">CXCursor_TypeAliasTemplateDecl</tt> tend to be template parameters, effectively leaking these parameters into the surrounding context.</p>

<p>Moreover, since the addition of <tt style="background: #ebebeb; font-size: 13px;">CXCursorTypeAliasTemplateDecl</tt>, references from <tt style="background: #ebebeb; font-size: 13px;">CXCursor_TemplateRef</tt> point directly to these cursors which, unfortunately, have a spelling range which covers the <tt style="background: #ebebeb; font-size: 13px;">using</tt> keyword that introduces the name which will refer to this alias, but not the name itself. Additionally, unlike <tt style="background: #ebebeb; font-size: 13px;">typedef</tt> cursors or <tt style="background: #ebebeb; font-size: 13px;">CXCursor_TypeAliasDecl</tt>, <tt style="background: #ebebeb; font-size: 13px;">CXCursor_TypeAliasTemplateDecl</tt> yields no useful information about the type it is aliasing; interestingly, <tt style="background: #ebebeb; font-size: 13px;">CXCursor_TypeAliasDecl</tt> provides this information without fault, even if it refers to templates with template parameters. Ultimately, this means that the actual <tt style="background: #ebebeb; font-size: 13px;">CXCursor_TypeAliasTemplateDecl</tt> 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 <tt style="background: #ebebeb; font-size: 13px;">CXCursor_TypeAliasDecl</tt> 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 <tt style="background: #ebebeb; font-size: 13px;">CXCursor_TypeAliasTemplateDecl</tt> to see if it can be made to function more like a traditional declaration cursor.</p>

<p>BUG: 384580<br />
FIXED-IN: 5.2</p></div></div><br /><div><strong>TEST PLAN</strong><div><p>I ran the entire test suite before and after my changes and noticed no new breakage. Maybe I should add a <em>gotcha</em> test-case for the leaked parameters?</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D7799" rel="noreferrer">https://phabricator.kde.org/D7799</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>plugins/clang/duchain/builder.cpp</div></div></div><br /><div><strong>To: </strong>craigt, KDevelop, mwolff, kfunk<br /><strong>Cc: </strong>kdevelop-devel<br /></div>