why is a source file parsed when being closed ? (was: Re: my first post)

[Tommaso Massimi]

On 12/7/05, Alexander Neundorf <neundorf at kde.org> wrote:
>
> Hi,
>
> I'm sending this again with a better subject, maybe this way it draws more
> attention :-)


well done!

On Tuesday 06 December 2005 17:58, Andreas Pakulat wrote:
> > On 06.12.05 17:20:27, Tommaso Massimi wrote:
> > > Hi all,
> > >
> > > a KDevelop's strange behavoiur (maybe a bug) is annoing me,
> > > so in the paste weeks I digged a bit about it.
> > >
> > > I found the fault already listed here,
> > > http://bugs.kde.org/show_bug.cgi?id=113379
> > > I added some details and a question about the source code
> > > where I think the problems is, but I had no answer.
> >
> > ?? What do you mean? Amilcar do Carmo Lucas added a comment.
>
> He wasn't exactly very verbose ;-)
>
> So this might be the reason too why closing a file is so slow in kdevelop
> ?
>
> void ProblemReporter::closedFile(const KURL &fileName)
> {
>    QValueList<Problem> problems =
> m_cppSupport->backgroundParser()->problems( fileName.path() , true ,
> true);
> }
>
> It seems this is done in order to remove the problems reported from this
> file
> from the problem view if the file is closed.
> I just tried with the call to problems() commented out, the FIXME from the
> closed file still disappears from the problem view. So this seems not to
> be
> the reason.

Anybody else knows why problems() is called there ?
> Is it required at all ?
> Would m_cppSupport->backgroundParser()->remove(fileName.path()); also do
> the
> job ?


finally I got the time to get a deeper look to the source code:

it seems that the BackgroundParser needs to be called because
it is also in charge to manage some other stuff like m_manager;
m_manager is an istance of the class KDevDriver which needs to be informed
of the file closure events because is storing info about the macros found in
the source file.

This means that deleting that line doesn't seems to be the right way to go.

In my opinion the best way to skip the trouble would be
to avoid to add wrong files to the background parser:

this is the function used to add a file to the list of files to be parsed:

void BackgroundParser::addFile( const QString& fileName, bool readFromDisk )
{
        QString fn = deepCopy( fileName );

        bool added = false;
        if ( !m_fileList->contains( fn ) )
        {
                m_fileList->push_back( fn, readFromDisk );
                added = true;
        }

        if ( added )
                m_canParse.wakeAll();
}

It seems it is only checking for duplicate files
(I hope m_fileList->contains( fn ) doesn't implement strange behavoiur...).


before add a file it could be possible to implement some more checks like:

- file size:
probably a big file is not a source file:
my troubles are coming out when I check the .dmp file generated by objdump
(I'm developing an embedded application,
so quite often I have to check the assembler code stored in a big file)
It could be possible to add some limit to the size of the file (1 MByte?).

- file type
why an assembler file needs to be checked by a cpp parser?
some others IDE are able to open hex files too,
looking at this code it seems that Kdevelop is cpp-parsing each file
is opened when a project is cpp based (NB: I could be wrong on this point).

Any comment from Kdevelop experts?

bye
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20051215/3c483584/attachment.html>