A systematic approach to code completion and c++ parsing/storage

Roberto Raggi raggi at cli.di.unipi.it
Sun Feb 10 18:54:02 UTC 2002


this is my approach to code completion for kdevelop 2.1...
when a user want complete a word i search the 'c++ expression' at left
of the cursor.. then i evaluate the expression in the current context.
the results of this evaluations is a list of word..

for example 
  
QString class1::method1( QString x ){
  ...
}
void class1::method2( int x, int y ){
   QString x;
   test( this->method1( "hello, world!" ). |  ,   arg2, arg3, ... )

'|' is the current cursor position

the left expression for me is this->method1( "hello, world!" ). 
and the context contains all symbol visible at the cursor position..

now i'm working on the evaluator

ciao robe

On Sunday 10 February 2002 18:33, you wrote:
> > On Sun, 10 Feb 2002, Falk Brettschneider wrote:
> > > In KDevelop-2.1 there's the possibility to use CClassParser::store
> > > which is of type CClassStore.
> > > This is still an unsolved issue.
> >
> > This seems to cause all the confusion, IMHO.
> >
> > I'd suggest splitting the code completion into several components to
> > incresase flexibility, maintainability and extensibility.
> >
> > /------------\
> >
> > | ktextexdit |
> >
> > \------------/
> >
> >       | (1) (i.e. request code completion)
> >
> > /-----------------\
> >
> > | language engine | (i.e. for C++)
> >
> > \-----------------/
> >
> >       | (2) (i.e. request members of a class)
> >
> > /-----------------\
> >
> > | language parser | (i.e. for C++)
> >
> > \-----------------/
> >
> >       | (3) (parse file(s) or load parsed ones)
> >
> > /---------------------\
> >
> > | file, or stored AST | (i.e. for C++)
> >
> > \---------------------/
> >
> > (1) is a request from ktextedit (I hope I got the right one :)) to the
> >     language engine for
> >   a) code completion (probably one of the simpler ones)
> >   b) refactoring (rename function in the appropriate namespace/scope)
> >   c) error detection/guessing
> >   d) invalidate all/part of a parsed document (to tell it has changed
> >      and needs to be parsed again in full or part of it)
> >   e) request code formatting (like indentation)
> >
> > (2) the language engine tanslates those calls for the structure of the
> >     internal AST (abstract syntax tree)
> >   a) request the members of a class that match a certain return type or
> >      more generally, a certain signature.
> >   b) request all variables, functions in a scope, namespace
> >   c) check the syntax trees for correctness.
> >   d) propagte 1.d to notify to reparse
> >
> > (3)
> >   a) parse the whole buffer
> >   b) parse part of the buffer
> >   c) load a saved AST (this can be left for later)
>
> I think (2) is useless - it must be language specific, so it's part of
> the language engine.
>
> I doubt we can work with ASTs. Well, it's good that we could use compiler's
> outputs for this but it's not good if we want to be error tolerant.
> The parser 'just' has to find out the parts of the file that are necessary
> for CC.
>
> Take a look at the attached sketch.
>
> Thomas





More information about the KDevelop-devel mailing list