Re: [anjuta-devel] Code assistance plugin

[Massimo Cora' <maxcvs email it>]

Hi,

On 05/26/2012 09:40 AM, Sébastien Granjoux wrote:
> Hi,
>
>
> Le 26/05/2012 01:37, Massimo Cora' a écrit :
> > > I would like by example to display a function call graph. Is it possible
> > > to get all necessary informations (which functions are called in each
> > > function) from the symbol-db plugin. If yes could I do it outside or
> > > should it be done inside the symbol-db plugin?
> > well, no. I think what you're looking for is
> > http://www.gnu.org/software/cflow/
>
> I don't care of a real implementation yet. I would rather define a
> common interface for to get all these informations.
>
> Currently it looks like we will have several interfaces, something like
>
> * For getting all functions of the project for completion we will use
> clang plugin.
>
> * For listing all functions of the project we will use the symbol-db
> plugin.
>
> * For getting the start and the end of a function we need something else.

well maybe with a facade we can define a common interface from the three 
modules, and make them available for the other plugins - a public 
interface. The three internal modules could instead collaborate and 
retrieve more infos on a symbol for instance.


> I would like to have one interface that could report all these
> information without having to know if it's done with clang, ctags or
> whatever. So by example, we could have the search plugin asking for all
> occurrences of a variable name within one function to replace it with
> another name.

ok it makes sense.

> > I would use clang for the completion and symbol-db for static file
> > analysis.
>
> Ok, but I think the important point is the user point of view. As user,
> I mean not necessarily a real user, it can be a search plugin. So what
> are the difference between clang and symbol-db result, isn't it possible
> to merge both result?

well, you should wrap for example what a symbol is, adding an adapter 
that let symbol db understanding a clang one is, or viceversa.
I think it's the only way to let the two communicate between each other.
When you have defined this, say AnjutaGeneralSymbol, you can switch the 
implementation details.

> By example if clang result are valid from C point of view but cannot
> includes accurate file line numbers due to expanded macros or whatever.
> When asking for a function information, I would like to get a file
> number field with some invalid value.
>
> So by example the search plugin knows that it cannot use this information.

we can fill the line results using ctags/symbol-db, providing the search 
plugin with a complete info.

> Then later if there are some improvements in clang or if we can use
> ctags in parallel this field could be filled and the search plugin will
> benefit immediately from it.

clang 3.1 has just been released. Did you have some experiments with 
clang? Has it the macro/line problems?

> > yes but we would have a really bad performance. That's because with
> > ctags you have to use a top-down approach instead of a bottom-up with
> > clang.
>
> We currently have code completion using ctags and it's quite useable.

for C maybe, but I wouldn't say the same for C++. Things get very 
complex there.

> Yes, I know. The gnome build autotools project parser was using a top
> down approach while the new one is using a bottom up but the interface
> is still the same.

the interface is the same, ok, but the results are maybe more precise.

Regards,
Massimo