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

[Thomas Schilling]

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: LE.png
Type: application/octet-stream
Size: 7002 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20020210/ba5a5b87/attachment.obj>