Longer List -- (Re: KFilterModel and assorted issues)

[Roberto Raggi]

Hi!

On Monday 06 February 2006 16:17, Adam Treat wrote:
> Awesome!  Pay particular note to how I disable the 'clear' and
> 'modelRefresh' signals from the aggregate to the proxy and reconnect them. 
> Tell Marius that one limitation seems to be that proxy's outside of TT's
> control don't have access to the underlying persistent index list.  I think
> the
> QPersistentModelIndex class that Qt4.1 exposes is useless.  I can't
> retrieve an instance of one from any model or proxy.  All I have to alter
> the persistent indexes is changePersistentIndex(...), but no way to
> retrieve a list of them like QSortFilterProxyModel does.
oki

> Now, Roberto, while I have your ear, the biggest thing I'd like to see is
> some attention paid to the location info in the
> parser/preprocessor/codemodel. Right now, I'm storing info, but it is *BAD*
> info as the locations are from the preprocessed source!!  We need some way
> for the preprocessor to build a table of locations during its pass and then
> somehow translate them to the codemodel during the parser/binder pass.
Yeah I know at the moment kdev-pp doesn't have the support for locations :
( I'll fix it as soon as possible. Anyway, I'll try to explain a bit my idea 
for the C++ language support. 

Preprocessing a file inside KDevelop and preprocessing a file in GCC (or 
insert your <batch> tool here) is pretty different. The point is *as always* 
the translation unit :-)

The translation unit for KDevelop is quite complex. Let's write a couple of 
examples to understand the problem.

example 1) 
You can see from this example that preprocessing a file in the *classic* mode 
"and removing unreachable" blocks is really bad :-) For instance, you *can't* 
use code completion for the expression "str." if WINDOWS is not defined!

void main ()
{
#if defined WINDOWS
  QString str;
  str.  <--- the cursor is here
#else
  // something here
#endif
}

example 2)
Resolve the #include directive is not exactly cheap :-) QtGui expands to *a 
lot of code*.. parsing the resulting file will take a lot of resources 
( memory + CPU + a lot of time :-) So in general you don't really want to 
resolve the #include directives.

#include <QtGui>

int main ()
{
  QString str;
  str. <-- the cursor is here
}

example 3)
this is very similar to the first example.. but here we have a different 
problem. In this case you *want* to preprocess the file, because otherwise 
the parser will fail(there is no way to match the braces without 
preprocessing) :-)

int foo
#if defined TRAITS
   (unconst_traits<T>::type a)
{
#else
   (T a)
{
#endif
  a. <--- the cursor is here
}

example 4)
We can't really have a good code completion engine without a *deep* 
integration with the build system. This example show the problem. The project 
has two files with name plugin.h. There is no way to pick the right one in 
src/main.cpp without some support from the buildsystem.


the project structure is
src
 src/plugin1/plugin.h
 src/plugin1/plugin.cpp
 src/plugin2/plugin.h
 src/plugin2/plugin.cpp
 src/main.cpp

// contents of main.cpp
#include <plugin.h>

int main ()
{
  Plugin1 p;
  p. <--- the cursor is here
}


example 5)
this is one of the problem we want to solve in KDevelop 4. We don't want to 
rename (using code refactoring) the preprocessed file, but we need to 
preprocess the file to compute the *valid* translation unit :(

#if defined DEF
#  define A(a,b) a + b
#endif

int main ()
{
  int xx = 10, yy = 20; <--- you want to rename `xx' using the code 
refactoring engine
  int zz = A(1 + xx, 2 + yy); 
}


So we need to improve the preprocessor with some KDevelop-specific feature, 
and my feeling is we don't want to resolve the #include directives for cpp 
files. But maybe we *have* to resolve the #include(s) for the .h files +  we 
have to be sure to parse all the header files before parsing the cpp files.


> For instance, if I have api.cpp as my currently active file and I modify it
> then it will be passed to the preprocessor as a QByteArray.  The
> preprocessor needs to be told what file it came from too ie, api.cpp. 
> Also, when the preprocessor goes through the includes it needs to query
> kdevelop whether a particular include is an opened file... because if it
> is, then kdevelop needs to pass it a QByteArray instead of the preprocessor
> just reading that include from disk.
yeah I know the problem :(

>
> So, api.cpp is passed to the preprocessor which records all the filename
> information for the various nodes and also the original location
> information and then this information need to be preserved for the
> parser/codemodel.  I can't stress enough how important it is to get this
> information **absolutely correct** for everything we do: problem reporter,
> code view, completion, etc, etc.
hmmm .. i'm not sure about it.. as I said before I think we should change the 
way preprocess files.

>
> Some other things while I'm going on at length:
>
> 1.  Trolltech needs to push hard on the necessary
for sure we will improve it.

>
> 2.  I'm going to work on loading language parts in tandem hopefully pretty
> right now as I'm anxious to see Jakob's parser in action.
I think it is OK for now. 

>
> 3.  I want to move the background parser to lib/* as I think this could be
> done in a language agnostic manner.  The background parser would just query
> the language support part for a ParseJob for the particular document that
> is activated.
please do it.. I'm all for it

>
> 4.  Some reorganization of the source I think should be on the table.  The
> classes in /lib* are scattered as it is and some of the things probably
> shouldn't be.
I agree

>
> Well, I guess that's good for now and I'm tired of typing.
:-)

ciao robe