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

[Gregor Zeitlinger]

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)

Instead of calls we can also use the slot/signal architecture, so that the
parser can notify the language engine or ktexteditor directly if errors
are detected so that they can be shown immediately
   
An advantage of this approach would be that it's relatively independent of
the editor interface (who knows how many different editor interfaces will
be adopted during the next few years?)

It's also easier to implement new features and lanuages and last not
least, to reuse existing code.
There probably is a class parser already. Is it CClassParser? If it was
generalized it could parse any c++. Since this is quite a difficult task
by itself already, it's better to seperate it. I'd try to help with that
nevertheless, since I was able to hande an SQL compiler.... (not that this
means anything) 
In a first approach I's suggest leaving out increamental parsing and only
parse whole files. But wait: heavn't we already been there. Didn't
somebody start with a tokenizer (flex)?
This might be a start to work bottom-up. Does anybody want to define the
interfaces top-down (from ktexteditor)?

I still have to get KDE3 running though....

-- 
Gregor Zeitlinger      
gregor at zeitlinger.de