If using a STL container from GCC 4.7.0 (with --std=c++0x), return type of their access methods like "std::vector<>::at()" is not resolved. This prevents the DUChain for members' access from being built: In this example: Reproducible: Always Steps to Reproduce: Sample code: ---- #include <vector> struct A { int fld; }; std::vector<A> v; v.at(0).fld = 0; ---- Actual Results: 1) No auto-completion after typing "at(0)." 2) "fld = 0" is not being highlighted 3) Auto-renaming of "fld" doesn't work. -> The DUChain for "fld = 0" is not being built. Expected Results: 1) Auto-completion of "fld" after typing "at(0)." 2) "fld" in "fld = 0" being highlighted as a variable 3) Auto-renaming "fld" correctly replaces both uses -> The DUChain for "fld = 0" is expected to build correctly. GCC version is 4.7.0, and c++0x support is enabled.
The problem seems to be located in <bits/alloc_traits.h>. The correct partial specialization of std::__alloctr_rebind is selected using third (bool) template parameter, which is resolved with a helper class std::__alloctr_rebind_helper, which in turn uses overloaded constexpr functions to select the correct value. The problem 1: Cannot handle constexpr functions while resolving constant expressions (in std::__alloctr_rebind_helper) The problem 2: Cannot handle constant variables while resolving default template arguments (in std::__alloctr_rebind) The problem 3: Something happens when resolving templated "using" declaration (in std::allocator_traits<>::rebind_alloc)
I confirm this also, it is pretty annoying indeed. Ivan, if you can spend some time to work on this it would be great... thanks a lot for your work on kdev anyway!
After some digging I started to think that it'd be better to accomplish this by completely changing our parser to clang... (There is some work for it (https://github.com/Gnurou/kdevelop/tree/clang), and I'm going to join it shortly.) Trying to improve _our_ parser will be greatly time-consuming as enabling such type resolution would require adding support for variadic templates and who knows what else.
What a great news :-) I'm also a kernel developer and that project looks really cool. Thanks again!
note that there's kdev-clang nowadays which is pretty good already and will be further improved over the coming months! checkout http://kfunk.org/2014/04/28/gsoc-2014-improving-the-clang-integration-in-kdevelop/ e.g. *** This bug has been marked as a duplicate of bug 324388 ***