Bug 384580 - Alias template parameter confusion
Summary: Alias template parameter confusion
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: Language Support: CPP (Clang-based) (show other bugs)
Version: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
: 372220 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-09-11 04:22 UTC by Craig Tenenbaum
Modified: 2018-03-15 19:10 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.2


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Craig Tenenbaum 2017-09-11 04:22:17 UTC
Remember yesteryear's https://bugs.kde.org/show_bug.cgi?id=368067 ? A new variant of this bug exists in clang releases since ~3.8 with regard to alias templates. The following code:

    class Foo;

    template<typename Foo>
    using Bar = Foo;

    class Foo
    {
        void foo();
    };

    void Foo::foo() { }

…now results in the same parameter confusion as in the referenced bug, I've opened this as a new bug only because the cause is novel. Currently, in kdevelop's clang support, the switch() default in visitCursor() in builder.cpp recurses into a given cursor. In Clang 3.8, a cursor was explicitly exposed for template type aliases (CXCursor_TypeAliasTemplateDecl), the children of this cursor consist of, first, a CXCursor_TemplateTypeParameter, and CXCursor_TypeAliasDecl. When one recurses into CXCursor_TypeAliasTemplateDecl, one ends up adding a use for whatever template parameter is specified in the alias. Additionally, formal template type alias use-tracking is broken owing to a mismatch between the cursor stored for the TypeAliasDecl and its parent.

It is worth noting that I'm currently trying to patch my issue with alias template tracking and such a fix would likely also resolve this bug, as I assume it just means hooking CXCursor_TypeAliasTemplateDecl into kdevelop's clang machinery.
Comment 1 Kevin Funk 2017-09-11 14:59:48 UTC
Patches very welcome of course, if you need help please join the IRC chat #kdevelop on Freenode.
Comment 2 Aleix Pol 2017-09-14 12:52:41 UTC
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
Comment 3 Kevin Funk 2018-03-15 19:10:15 UTC
*** Bug 372220 has been marked as a duplicate of this bug. ***