https://bugs.kde.org/show_bug.cgi?id=384580
Aleix Pol <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Latest Commit| |https://commits.kde.org/kde | |velop/54a8aa75f94e750bb303f | |6fa5eae6475996c0542 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Version Fixed In| |5.2 --- Comment #2 from Aleix Pol <[email protected]> --- Git commit 54a8aa75f94e750bb303f6fa5eae6475996c0542 by Aleix Pol, on behalf of Craig Tenenbaum. Committed on 14/09/2017 at 12:51. Pushed by apol into branch '5.2'. Type Alias Template fix 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 (they presently do not). 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. FIXED-IN: 5.2 Test Plan: Modified extant testTypeAliasTemplate test in test_duchain-clang to verify this patch works as expected, namely, that it doesn't leak template parameters into the surrounding context, and that uses of the type alias template are correctly tracked in the DUChain. If you simply apply the changes to test_duchain.cpp on their own, the breakage of the current code model becomes apparent. Reviewers: #kdevelop, mwolff, kfunk Reviewed By: #kdevelop, mwolff Subscribers: apol, kdevelop-devel Tags: #kdevelop Differential Revision: https://phabricator.kde.org/D7799 M +55 -0 plugins/clang/duchain/builder.cpp M +8 -3 plugins/clang/tests/test_duchain.cpp https://commits.kde.org/kdevelop/54a8aa75f94e750bb303f6fa5eae6475996c0542 -- You are receiving this mail because: You are watching all bug changes.
