c++ code completion status report

[Thomas Schilling]

> > So the parser has to be able to evaluate an arbitrary
>                                                 ^^^^^^^^^^^^^
> > expression concerning it's result type to determine what
> ^^^^^^^^
> > to do/show.
>
> I think you've eaten too many brownies in new year's party :)

Only some cookies by my grandma :)

>  However, you
> should _not_ evaluate any expression. What you refer to is static type
> analysis and you should not try to go beyond that.

Of course I cannot achieve dynamic type checking. Or what
do you meen with 'static'? But consider this example:
 ((MyClass)c)->member. // ...
This is a typecast and should be recognized.

> It would be much better to use  a dependency grammar for that purpose. You
> should be using an attribute grammar rather than inventing how to write a
> parser. (It looks like there are many available implementations) And you
need
> only a type analyzer, which isn't too difficult: however typedefs and
> templates complicate this matter beyond recognition. My advice is to first
> make a thorough survey of what other people have done.

Hm, the latter is hard since we're somehow under time pressure.

But how about this:
- A file is analysed, External file information is obtained through
the class-store (i.e., parsed some time before). All declarations
are parsed and only the statement or declaration the cursor is
resting at is 'evaluated' (transformed into an expr-tree or
something like that). Then it's type may be examined and the
show can begin ...
- There also must be a way to determine what kind of code
the cursor is at (e.g.: identifier -> show type,
function params -> show decl, etc.)

To the first: How to manage that (dependency grammar)?
Never heard of this before. Would it really work with C++?

> No, the best method is an incremental parser, which is beyond the
> capabilities of our middle-level imperative implementation language, of
> course unless we have a clever coder who can devote the rest of his life
to
> implement an incremental LALR parser + type semantics.

Looks like a good research topic ;) Of course this would be best.
But actually it wouldn't. Best would be if UNIX systems had some
kind of knowledge center where you can easily find what progs exist
and how you could customize them and so on, and there we would find
_the_ C++ Parser that is:
- always up to date
- accessable via a powerul api
- has some incremental mode.
But I think we have to dream on ... :(

> In our constraints, the best way is of course not to parse the entire
file,
> with all its includes, every time a character is pressed, right?

Sure! My first idea was: only when '.' or '->' was typed
but that ain't extensible.

> should be doing is to approximate an incremental parser by storing all
type
> analysis in a database, and try to update that information which has been
> changed. That is, compute only lazily. The required level of granularity
is
> per-file. Store the type analysis results of all project-files in the
> database. Also required is a simple inference engine to account for
> inter-module dependencies. Dependencies determine whether type analysis is
> required for a given module.

That's all peanuts ;-)
I.e. it's planned (but I haven't mentioned it explicitly)

> Doing the type analysis correct and complete for C++ language doesn't seem
to
> me as easy as you describe, though.

I mentioned it in the mail before: it's _really_ hard.

> Also, the only application of such a code should not be code completion.

For me some other code 'completion' features are:
- array initialization: show current position
- identifiers: show type/doc/file/place ...
- autochange function declarations (if one changed)
- completion for:
  + base class members (for overloading)
  + members (what most undestand of cc)
  + function/template default args
- file survey generation (vars, ns, includes, ...) as we already have a bit
- etc.

Now I'll take a look at sourcenav ...

- Thomas