Guidance needed to contribute to kdev-clang

[Milian Wolff]

On Tuesday 11 February 2014 11:23:33 Olivier J. G. wrote:
> On Mon, Feb 10, 2014 at 6:30 PM, Maciej Cencora <m.cencora at gmail.com> wrote:
<snip>
> > 2) same data/function member use is colorized differently in header file
> > and in source file
> 
> Not sure I can identify this problem... are you talking about old-cpp's use
> of orangish for member variables/declarations?

I also need example code to understand what you mean here. Maybe also a 
screenshot or two?

> > 3) no navigation widget on class scope specifier for out-of-line member
> > function definitions
> > class Foo
> > {
> > 
> >     void bar();
> > 
> > };
> > 
> > void Foo::bar() {} // "Foo" not navigable, but colorized
> 
> This is strange. Possibly something going wrong with use creation
> (tuduchain.cpp:157), but it seems to create a valid use...

Generally, look into the context browser, add/enable debug output and figure 
out why it does not trigger a navigation widget to be shown. Maybe declaration 
under cursor fails for some reason?

> > 4) no navigation widget and colorization of destructor declaration
> > class B
> > {
> > 
> > public:
> >     ~B() {} // "~B" is not navigable, and not colorized
> > 
> > };
> > ...
> > B b;
> > b.~B(); // "~B" is not navigable, and not colorized
> 
> Hmm, the range we get for the destructor (from clang) only includes the
> tilde. Possibly we should create a use of B here; two problems with that
> are that we don't seem to get a use cursor, and that would be strange VS
> the constructor (which is a function). Maybe investigate the cursor and
> range that clang gives us here (TUDUChain::visitCursor)?

Yep, I'd say here we should extend the range to encompass "~B" and not just 
"~".

> > 5) no navigation widget for uses inside user defined subscript operator:
> > int getInt();
> > std::map<int, int> c;
> > c[getInt()] = 0; // "getInt()" is not navigable separately but whole
> > [getInt()] is
> 
> This is because the use of operator[] takes that whole range. A solution
> might be to customize the range for an operator[] use to just include the
> opening "[".

Exactly.

> > 6) no navigation widget for uses of other overloaded operators
> > std::cout << 1; // "<<" is not navigable
> 
> This is odd. One could check if we get anything in TUDUChain::visitCursor
> ...

We should, but probably we fail to find the use for it. See the output of 
clang-parser -a on a sample file using the above:

        use: "__ostream_type &(__ostream_type &(*)(__ostream_type &)) 
operator<< " of kind DeclRefExpr (101) in test.cpp at 5:18                

I bet we cannot find the declaration with that identifier. The old-cpp used 
strange special identifiers for operators, and maybe thats due to a limitation 
somewhere and we must do the same here. Must be investigated -> Add a simple 
example with a custom operator overload and ensure the use is build correctly. 
Then investigate and fix it in tuduchain.*


> > 7) no navigation widget or colorization of uses of template parameters
> > template <typename Type> // "Type" is colorized but not navigable
> > class A
> > {
> > 
> >     Type member; // "Type" is not navigable, and not colorized
> > 
> > };
> 
> TUDUChain::visitCursor is again the entry point to finding out what's going
> on here. First question: are we creating a Declaration or a use for the
> "Type" in "<typename Type"? We should be creating a declaration. Next
> question, what cursor, if any, do we get for "Type" in "Type member;"? It
> should be a use of the declaration in "<typename Type>"

Again, should work, clang-parser -a says:

AST tree successfully generated
decl: "A<Type> " of kind ClassTemplate (31) in test.cpp at 2:7
  decl: "Type Type " of kind TemplateTypeParameter (27) in test.cpp at 1:19
  decl: "Type member " of kind FieldDecl (6) in test.cpp at 4:6
    use: "Type Type " of kind TypeRef (43) in test.cpp at 4:1
no problems encountered during parsing

My guess is that the declaration is not found for whatever reason. Add a test 
and investigate it in tuduchain*

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de