Tue, Apr 16
patch lgtm now, many thanks!
Mon, Apr 15
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.
Re-add m_diagnosticsCache with a hopefully correct caching implementation. Differing from the original situation, the new function createExternalProblem() adapts the problems it creates to the specific file they are inserted in. The cache thus only caches the original problems as created by ClangDiagnosticEvaluator::createProblem(). createExternalProblem() makes copies of these with a new copy constructor added to ClangProblem.
quite obviously libclang doesn't handle it
Do you mean something like `#include <Foo>` which then contains a `#include <foo.h>`?
Sun, Apr 14
I am sorry, I think that I misunderstood how the cache works. Please disregard my previous message. I am wondering where the problem that I've been seeing then comes from, seems like it has a different origin.
Sat, Apr 13
I re-tested the behavior on files from an actual project and it showed the same behavior when editing files as described in my last post, regardless of how many files are included from the files that are edited. I noticed that the behavior is different when re-opening files: in this case, problemsForFile() is actually called for a larger set of files (although from only looking at this set of files, it seemed a bit random and it was not clear to me how it is determined, I'll have to dig into the source code for this at some point ...).
Oh, really? Hmm! I wouldn't be opposed to enable compilation with exceptions myself, what do the others say? We don't need to use them excessively, but for error handling in async promise chains, that would be quite useful I think?
Hey Thomas, please don't remove the cache. See f2a6941e086cdf506c8fb1798c52982bff43792d for why this was introduced. Your tests don't include other files, so probably that's why you didn't see any effect of the cache?
Tue, Apr 9
Probably not - this is my first commit. Where do I need to apply :-D
Good stuff, do you have push rights?
Mon, Apr 8
Upload correct patch
Yeah, you're right.
I think you uploaded the patch against the last version, not against master.
Sat, Apr 6
Thanks for the info. I didn't spot it at first since it is hidden in a dropdown menu.
Address Milian's comments; remove m_diagnosticsCache.
@thomassc it is because I commandeered your revision to be able to update it. If you want, you do the same. First select "Commandeer Revision" at the bottom of this page, and then use arc diff (possibly with --update D18567) to update it.
Thanks for the update. Seems good to me.
Fri, Apr 5
Work through feedback:
Thu, Apr 4
After finishing initial implementation I found out that QtPromise requires exceptions enabled. KDevelop seem to have exceptions disabled right now.
Tue, Apr 2
I will do that.
Mon, Apr 1
As long as it integrates well with the rest of the KDevelop build I'm fine. Would probably just copy the QtPromise source tree into maybe kdevelop.git:3rdparty/ and create a CMakeLists.txt which creates a STATIC or OBJECT library for it? QtPromise looks easy enough to build.
yes, QtPromise or AsyncFuture (https://github.com/benlau/asyncfuture) could be used - I wouldn't be opposed to introducing it as a thirdparty dependency (or git submodule)
KAsync looks a bit unmaintained. On the other hand, QtPromise seems to be an active project. Should I start looking into the latter?
if it applies cleanly, you can also push to 5.3, otherwise master is fine - it's not a really urgent bug fix after all (imo)
Sun, Mar 31
Looks good to me overall, Let's clean it up so we can get it in.
How it looks.