Code completion and interative syntax (semantic) checking

[Thomas Schilling]

Moin,

> > If you do it - no problem ;-)
> did I say that I _aleways_ underestimate computer work?
But maybe you underestimate C++. (see below)

> > Do you have a _complete_ C++-syntax?
> No. Doesn't gcc have one?

There's one you can download at comp.compilers
(i don't know the exact url)

If you have further questions, ask me, I have the C++ inventors
book.

> > left-alone nodes that can be destroyed by nobody.
> this could be solved by registering all tokens somewhere. From there they
> could be deleted.

So using an overloaded 'new'? I hoped to avoid this. But otherwise
it should b no bigger problem.

> > see victor's mail -> the class-store (i guess - or better ask
> > exa = Eray Ozr... can't spell it, see the mailing list)
> could somebody give a pointer?

Eray just wrote a mail on this subject.
(His real name is: Eray Ozkural - sorry Eray .. was too lazy to look it up
;-)

The problem is that it has no type evaluation - the important part for CC.
But it has parsers for several languages and a good persistent classstore.
I don't know how much error tolerance we need and how much error tolerant
SN's parsers are and how much tolerance we need.
At least it shouldn't break down when you missed a ';' or so.

> > > > We have CppSupportPart (see gideon: parts/cppsuppoert )
> > > I don't have an overview of the architecture. It should be generic
enough
> > > to support other languages as well. And so should our library.

So should we start a poll or so to find out what other languages need?

> > WHAT? Wow. What a big plan, eh. That will be really hard!
> well, see above. The very cruitial point is to set up the architecture.
> Once that's done, other people may add implementations of their favorite
> language

Sounds good - but also like a lot of work ...

> > Or... do you mean just the interface? <:-|
> the interface plus a generic language parsing part. For an actual language
> you would need to derive a couple of virtual classes and provide a flex
> and bison file of course. A symbol table would belong to the generic part.
> And the interfaces for variable scoping. Just brainstorming...

We have the class store: the parser part fills it and the CC part uses it.

Concerning TextEditorIface: I'd like to have a content survey just like
delphi has - i mean a kdevelop-independent - so the text part should
own the cc-parsers

> I'm afraid I won't be able to do much until March except coming up with
> ideas that are horribly complicated :)

We'll tolerate this :)

> > You already have some code ready? Goooood. Send it and we'll check it.
> Well, it has to be refined and it's for SQL :)

ohhh. From there comes the optimism. Well but i think SQL is much more
complicated than SQL. But we'll see how your ideas will work.
(Cosinder: namespaces, extern "C", operator overloading, function
overloading
-> you have to determine the actually called out of the arguments ...)

> if that's one one line by itself: yes. The tricky part is to find a
> reentrancy point. Let's suppose it looked like this
>
> a = b.
> c = d;
>
> Now this is infact a no syntax error, because syntax checking ignores
> context. c could be member of b. The semantic check might find out that
> there's no such member. After the syntax check, your ast (abstract syntax
> tree) will look as follows:
>
>    =
> a     =
>    b.c d
>
> Now the semantic check will tell that d may not be assignd to b.c and b.c
> not assignd to a. Now the tricky part is finding out that a simple ";"
> instead of "." would have solved the mess. A possible solution is
> calculating the follow set of a token: it's the set of tokens that may
> follow a token.

hm (see below)

> Since ";" is part of follow("id = id") it may be tried. It looks very
> complicated though.
agreed, looks really complicated.
let me tell you our current idea:

below is here:

0. the CC parser (the one that get's the type info) is called only when
special tokens were typed (at least in the current version)
1. the CC parser  only gets the stuff (code) up
to the cursor. (optimally only from the last ';' '{' or '}' on to the
cursor)
2. it 'anyhow' get's the current scope (maybe by line numbers from
the class store)
3. it parses the string - it should actually be just a single statement -
and assumes that it is in the scope (CS node) to find out the types
of the identifiers found there. To avoid being confused by earlier
unfinished statements (e.g: "a = 6; a.b(  c." is the text before the
cursor, so the CCparser would get "a.b( c.") we can even try to parse
backwards.

> > And _that's_ much hard work, i guess.
> I've got the impression that getting used to bison is difficult. _Then_
> it's actually pretty useful.
I hoped so, too. But I returned to plain C++-code. But maybe you like it
more.

> > I'm working on it. We also have some other problem: the CS is used also
> > by other languages.
> yes. It's quite a challenge. It's probably best to go for a both a
> short- and longterm solution.

So how about the poll?

> That way something's ready for KDE3. Because the generic solution probably
> isn't by then.

we'll see

Thomas