c++ code completion status report

[Richard Dale]

On Thursday 03 January 2002 9:52 pm, Thomas Schilling wrote:
> C++ CODE COMPLETION
>
> Seems it's an impatiently expected feature.
> So I'll give you a short survey of what issues
> we're struggling with. (Until now we held our
> discussion in German and outside kdevelop-devel).
If you're struggling then please contact this list (and you have done now 
that's great :) ). I think there are plenty of people who can help with 
flex/bison parsing issues etc. If translating to english is a problem, then 
could the german discussion be run through babelfish or similar? Then english 
speakers know what's going on and can maybe help out?

> The first features the C++ code completion (CC)
> will support are:
> - member completion
> - argument hinting/completion
> - type information
>
> About 100 more features are conceivable but
> the time ... ;-)
>
> Undoubtedly we need a parser. Therefore we
> had to learn BISON (at least I had to) and even
> before had to find out that we had to learn about it.
> It seems that work will continue faster now but
> it's still a lot of work and C++ has a very complicated
> grammar with many many ambiguities.
>
> If someone want's to help he/she(?) should first
> read the FLEX manual ("man flex") and the BISON
> documentation ("info bison" or GNU website).
I can't find any bison grammar in cppsupport. I see two flex grammars with 
minor differences:

tokenizer-cc.l  tokenizer.l

'tokenizer-cc.l' has these extra tokens:

    /*==> added by DANIEL <==*/
<INITIAL>"emit"           {return CPEMIT;}

<INITIAL>"void"           {return CPVOID;}
<INITIAL>"int"            {return CPINT;}
<INITIAL>"bool"           {return CPBOOL;}
<INITIAL>"float"          {return CPFLOAT;}
<INITIAL>"char"           {return CPCHAR;}
<INITIAL>"static_cast"    {return CPSCAST;}
<INITIAL>"dynamic_cast"   {return CPDCAST;}
<INITIAL>"for"            {return CPFOR;}
<INITIAL>"while"          {return CPWHILE;}
<INITIAL>"do"             {return CPDO;}
<INITIAL>"if"             {return CPIF;}
<INITIAL>"else"           {return CPELSE;}
<INITIAL>"switch"         {return CPSWITCH;}
<INITIAL>"case"           {return CPCASE;}
<INITIAL>"break"          {return CPBREAK;}
<INITIAL>"default"        {return CPDEFAULT;}
<INITIAL>"return"         {return CPRETURN;}

If you only want these tokens to be parsed in a 'more detailed' parse phase 
why not have one flex grammar and use the 'REJECT' macro to reject these 
tokens if doing the standard 'less detailed' parse for the class tree, as 
oppposed to code completion?

eg
 
<INITIAL>"break" { if (classParserPhase) {REJECT;} else {return CPBREAK;} }

So if 'classParserPhase' is true, it will drop thru' and match a catch all 
rule further down, and return some other token. Or you could do something 
similar with start states - have a start state for 'more detailed' code 
completion parsing.

<CODECOMPLETION>"break"          {return CPBREAK;}

> Currently the most promising approach for the
> CC parser is one big parser that creates sort of a
> parse tree that is evaluated by the different aspects
> of the CC part.
That's the current class store structure with extra 'more detailed' attributes 
I assume?

-- Richard