Can't we really fix this without bringing a dependency?
If we really want the dependency, can we just link against it instead of dragging it into our source code?

Changes:

• Import QtPromise 0.5.0 into kdevplatform/3dparty/ directory.
• Remove synchronious KIO calls from Project::open() and use QPromises there instead.

In D21156#465844, @mwolff wrote:

you are removing a feature, but only partially - a lot of code would become superfluous by this change and should be cleaned up accordingly

you are removing a feature

you are removing a feature, but only partially - a lot of code would become superfluous by this change and should be cleaned up accordingly

Sounds good enough for me then!

With the Alt key the bug does not appear, because the existing code disables correctly the browse mode when Alt is released. For some reasons key press and release events are different for Ctrl key but are the same for Alt. Probably the method avoidMenuAltFocus manages this behavior correctly for the Alt key (I have not analyzed in detail what it does) and then we enter correctly in the if at line 230 where source browse mode is disabled. So removing the redundant Ctrl key solves the bug completely (at least I haven't manage to reproduce it).

You identified an event chain which leads to the browsing mode not being restored correctly. This should happen less often with the Alt modifier but it can still happen (hit Alt to display a tooltip or open a menu and then move the mouse over that tooltip or select a menu item?).

• Disable Ctrl and keep only Alt

Feel free to push it into the 5.3 branch then.

No problem. I don't think I'm yet involved enough to apply - besides being a user.

In D20142#446500, @christiant wrote:

Probably not - this is my first commit. Where do I need to apply :-D

Anything I need to do?

patch lgtm now, many thanks!

In 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.

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>`?

In D18551#430847, @rjvbb wrote:

Re: reparsing reliably each time a headerfile is changed: wouldn't the use of forwarding headers increase the chance of missing a change?

In D18224#449416, @thomassc wrote:

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 ...).

In D18758#450081, @apol wrote:

In D18758#449319, @mwolff wrote:

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?

That would mean adding a bunch of noexcept all over the place or risk quite some performance penalty. I'd prefer keeping it localised.

In D18758#449319, @mwolff wrote:

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?

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.

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 ...).

In D18758#449319, @mwolff wrote:

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?

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?

thanks, lgtm!

Probably not - this is my first commit. Where do I need to apply :-D

Good stuff, do you have push rights?

Upload correct patch

Yeah, you're right.

I think you uploaded the patch against the last version, not against master.

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.

Work through feedback:

Simplify code.

After finishing initial implementation I found out that QtPromise requires exceptions enabled. KDevelop seem to have exceptions disabled right now.

I will do that.

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)

Onto master?

Looks good to me overall, Let's clean it up so we can get it in.

How it looks.

I don't remember details of this revision, but at least it seems to do like how we agreed.

Remove API changes and just sort plugins list.

Of course, forgot to tell. Now we are in gitlab:
https://invent.kde.org/kde/kdevelop

In D19861#434135, @apol wrote:

Yes, sorry :)

Yes, sorry :)

In D19861#433859, @apol wrote:

Can you send the patch?

Can you send the patch?

Not really: it says that a temporary directory for every kdevelop instance is created

Then the best should be to file a bug on bugzilla.opensuse.org asking for that to be packaged.

In D17760#432630, @lbeltrame wrote:

Is this part of the astyle tarball, or a separate project?

Is this part of the astyle tarball, or a separate project?

In D17289#432577, @rjvbb wrote:

no need for making it "deterministic" in any way. There is no benefit in doing that.

I think there is so, it's the whole point of this PR.

no need for making it "deterministic" in any way. There is no benefit in doing that.

In D17289#432537, @rjvbb wrote:

OK, I stand corrected on this. OTOH, the rest of my notes about this being wrong anyway still stand.

I'm not convinced about those arguments but have no objection either to making the temp dir user-exclusive - it's a detail that should be easy enough. There's probably a reason I'm not using QTemporaryDir though

OK, I stand corrected on this. OTOH, the rest of my notes about this being wrong anyway still stand.

In D17289#432517, @rjvbb wrote:

using the user ID is definitely wrong here: with this change, opening a second kdevelop will erase the temporary directory of the first...

Maybe test-drive the patch (like I have been doing) before advancing hypotheses - don't you think I'd have noticed this kind of astronomically stupid error?
The tmp.dir name also includes the session ID, and you can only open a given session once.

using the user ID is definitely wrong here: with this change, opening a second kdevelop will erase the temporary directory of the first...

In D17760#428926, @arrowd wrote:

In D17760#428860, @cullmann wrote:

Question: does any distro package that?

At least my openSUSE doesn't nor any other distro I know of, only thing I found was:

https://rpmfind.net/linux/rpm2html/search.php?query=libastyle-devel

I skimmed through https://repology.org/project/astyle/packages and found none.

• add some rudimental version detection of the astyle library, since it provides no pkg-config file nor version macros/variables...
• request libastyle >= 3.1

Milian Wolff wrote on 20190312::20:02:54 re: "D17289: KDevelop/Shell: set dedicated TMPDIR"

That's right, thanks a lot!

Re: reparsing reliably each time a headerfile is changed: wouldn't the use of forwarding headers increase the chance of missing a change?

Note: It's Thibault North <thibault.north@gmail.com>