D18224: Clang Plugin: Report some problems from included files

Milian Wolff noreply at phabricator.kde.org
Tue Apr 16 14:34:17 BST 2019

mwolff added a comment.

  In D18224#450943 <https://phabricator.kde.org/D18224#450943>, @thomassc wrote:
  > > Upon reopening a file, we should only update the problems of changed files that got updated. Otherwise we should only grab the TU for the main .cpp file and attach it, such that we can do code completion.
  > If I understand this correctly, then perhaps something does not behave as it should there, since in some cases, a lot of files' problems seem to get updated when re-opening a file, including lots of system headers that certainly haven't changed. In other cases, no calls to ParseSession::problemsForFile() are made. It seems that the first case can be triggered by making changes to a header, closing it without saving, and then re-opening it.
  I'll have to try that myself once I find the time.
  >> Apparently you've figured out that this statement is wrong :)
  > Yes, I am really sorry here, as I apparently got confused thoroughly. I think that I first introduced a bug to the cache myself that caused the described behavior, and then I observed a similar symptom with the original code (which however came from another bug), which lead me to strongly believe that this same issue that I had introduced must have been present in the original version as well ... this should really not happen.
  Yeah, our code base is somewhat convoluted in some places, esp. once we try to make things faster we usually end up introducing such strange corner cases. I wouldn't be surprised if there are issues lying dormant here!
  > The other bug is that sometimes, KDevelop reports that include guards are missing in a header, when there is actually a #pragma once there. I don't know yet why this happens, but it is possibly unrelated here.
  Yes, I've seen this issue. It would be awesome if you can figure that one out - it's been around for a very long time. I always thought it's libclang that erroneously says that the header isn't guarded while it actually is. You say: maybe we associate a warning from a different header and that gives us this spurious warning? Maybe! Please investigate, if possible (in a separate patch)

  R32 KDevelop


To: thomassc, #kdevelop, mwolff
Cc: aaronpuchert, pino, mwolff, kdevelop-devel, glebaccon, domson, antismap, iodelay, alexeymin, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20190416/54de879b/attachment.html>

More information about the KDevelop-devel mailing list