Review Request 119959: Do not create multiple chains/env files on update.

Milian Wolff mail at milianw.de
Wed Aug 27 20:49:08 UTC 2014


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119959/
-----------------------------------------------------------

(Updated Aug. 27, 2014, 8:49 p.m.)


Review request for KDevelop and Sergey Kalinichev.


Changes
-------

fixed assertion when forced update is requested (we don't store that)


Repository: kdev-clang


Description
-------

The implementation of ClangParsingEnvironmentFile::matchEnvironment
was too restrictive. A "match" should just indicate that a given
DUChain is valid for a given environment in principle, not whether
its environment is equal (or so I think right now).

Otherwise, we end up creating multiple TopDUContexts with associated
ClangEnvironmentFiles whenever the environment has changed and a
reparse is triggered.

Properly update environment and modification revision of includes.

Otherwise these files will be parsed over and over again since
neither their environment, nor their timestamp is updated properly.

This hopefully fixes the slowness during code completion.


Diffs (updated)
-----

  clangparsejob.cpp 578d3abbb84671113da43eab9f7bb0401c7f71e1 
  clangsupport.cpp 7d091eb3873a973ae283dcdafb9551d0fd16d325 
  duchain/clanghelpers.cpp 6db552dfde667335a145d99852efbb3a74985f50 
  duchain/clangparsingenvironmentfile.cpp b7d903c9961beeecaca7438d7f5c96be5394387c 
  tests/test_duchain.cpp d0146c92f8a7d878aaca8266d6c3f07b24a60701 

Diff: https://git.reviewboard.kde.org/r/119959/diff/


Testing
-------

The unit test now passes, but I could never reproduce this:

commit fccc9b4311abb8f858c18e80348df8d3e09b1ce3
Author: Sergey Kalinichev <kalinichev.so.0 at gmail.com>
Date:   Tue Aug 19 21:54:57 2014 +0400

    Implement ClangParsingEnvironmentFile::matchEnvironment
    
    Now code completion is so much faster!

so I don't know whether the code completion is now slower again? Anyhow, if that is the case we'd need a different fix anyways.


Thanks,

Milian Wolff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20140827/65a79325/attachment.html>


More information about the KDevelop-devel mailing list