D18224: Clang Plugin: Report some problems from included files

[Thomas Schöps]

thomassc marked 14 inline comments as done.
thomassc added inline comments.

INLINE COMMENTS

> mwolff wrote in parsesession.cpp:505
> this isn't correct anymore:
> 
> When we run into this code path with, say, 5 problems, we would reserve with 5 and then fill the cache. When we then get back here the next time with 0 problems, we would reserve 0, but the size would still be 5!
> 
> the easiest solution I can come up with for now is to resize to output_index at the end... but I kind of dislike that we need that to begin with :( can you come up with something better? otherwise, please at least introduce a lambda helper that wraps the "lookup in cache and reuse or insert new problem"

To be honest, I am not sure how that cache is supposed to work. I did some testing with debug output added to ParseSession::problemsForFile(), and my impression is that it is currently broken. The behavior seems to be the following:

- When editing a source file, the cache always starts out empty. problemsForFile() is only called once for that source file. The cache is thus not used.
- When editing a header file, problemsForFile() is called first for that header file and then for some source file which is probably supposed to include that header (but did not always actually do that in my tests). The cache is empty at the start of the first call, so it is not used there. At the start of the second call, it contains the elements added by the header, but the function is now called on the source file, so the cached elements are wrongly used for it. So, the only use of the cache is a wrong use.

In case these observations are true and I didn't miss anything, could the cache be simply removed?

> mwolff wrote in parsesession.cpp:541
> use ki18n too
> 
> are we sure that this external problem will always have a location within the current `file`? couldn't it happen that we encounter completely unrelated errors? I would assume that e.g. in the following scenario, we may end up creating unhelpful issues?
> 
> A > B > C
> 
> if B has an error due to C, then A shouldn't show anything (except when we "show imports")

This should only happen in case of missing includes. In this case, it is intentional to show these errors since they may cause other errors later. Other types of problems with location outside of the current file are filtered out above:

  // missing-include problems are so severe in clang that we always propagate
  // them to this document, to ensure that the user will see the error.
  if (diagnosticFile != file && ClangDiagnosticEvaluator::diagnosticType(diagnostic) != ClangDiagnosticEvaluator::IncludeFileNotFoundProblem) {
      continue;
  }

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D18224

To: thomassc, #kdevelop, mwolff
Cc: aaronpuchert, pino, mwolff, kdevelop-devel, gennad, 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/20190406/93d69c8e/attachment-0001.html>