Re: [anjuta-devel] Code assistance plugin

[Sébastien Granjoux <seb sfo free fr>]

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.


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.



> 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?


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.

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.



> 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.


> The top down approach requires high usage of regexes, data dictionaries
> and guessing. That's why its complexity soon becomes unmaintainable and
> error prone.
> The bottom up approach is much more a low level parsing task, but we've
> already have it done with the clang compiler. Each C expression is then
> immediately solved with return type, members, etc.

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.

I think these are implementation details and I'm afraid that these 
details are visible in the interface. Then perhaps it's unavoidable, 
there is always a trade-off, but I would like to understand what are the 
choices here.


Regards,

Sébastien