I personally think it's useless to have this, but if others want to have it, fair enough. I just hate that this means a partial rebuild + relink when committing/rebasing without changing code.

Great work, I wonder if we could get some basic plugin json validator integrated into our buildsystem... would be useful for such situations, I guess!

As I said, I also need your email address so I (or someone else) can push this for you

Could you write a unit test for the broken behavior? It seems to be somewhat related to the changes done to the AutoTestShell::init calls, so writing an explicit test for that which fails beforehand and passes now would be appreciated.

why?

Actually, I'll need to know your email address - otherwise I cannot commit it for you.

I'll clean this up and commit it to 5.2, thanks!

this is not abi compatible, cannot be done -2

grepping in my ~/.config doesn't bring up any match, so lgtm

Can you please put the benchmark into a separate review as I requested? It must be self-contained, the "do stuff in background" change should then depend on that revision.

In D7995#149435, @rjvbb wrote:

About that benchmark: if a properly adapted fork of the abstractfilemanagerprojectimport test is NOT what you want you'll have to describe what you do want in a much more detailed fashion, so I can see if it's an effort I can accept to make. Not because I'm lazy, this really has been keeping me from doing more urgent things already.

Also, I'd love to see this tested, but it's probably going to be somewhat complicated to do that. TestDUChain::testGccCompatibility could be used as a basis, i.e. to setup a custom project with some custom compiler flags that trigger the test for both to check that we only report warnings, not errors

more nits, sorry :P

minor nits, lgtm in general now

the benchmark is required for testing this properly. Also it allows us to verify the thread safety using helgrind or tsan

You didn't add the ProjectWatcher code. Note that your statement regarding reentrancy makes it sounds like you do not understand thread safety vs. reentrancy. If you access the same KDirWatch from multiple threads, you _have_ to protect it via mutices. But at that point, I'm actually not sure whether that is enough... we'll have to talk to @dfaure about this... Is it enough to protect the KDirWatch from the outside with a mutex? I mean, what happens when an inotify event comes in - where is that being handled? Who guarantees that this is not going to get run in parallel to code we protect by our own mutex?

no time to review in-depth right now, but pretty please: write a benchmark! Instead of littering the code with timers here and there (you can do that, too - locally, if it helps you), write a benchmark that measures these numbers. Do it in such a way that we can compare before/after. This also allows us to test this code in a much better way, by running the tests locally.

Because Path is a generic data structure. Doing it at the place where it's being used allows this feature to be handled in a much faster way for the common case. The UDSEntry from a KIO list job e.g. knows if something is a symlink already and we can then canonicalize the path as needed. Your patch would add the overhead of this duplicate check to every user.

• you can use arc (the phabricator CLI) to submit patches
• you can use ctest to run tests in CMake based applications (go to the build folder, run ctest)

-2, I deliberately did not implement Path in this way and it should not be done. Users of Path should properly canonicalize the Paths. Feel free to add more asserts like those that exist in the DUChain to verify that paths are properly sanitized as-needed.

You need to provide us with a way to setup a project to trigger this problem, then one can build a unit test out of it.

Imo this should be done in the clang plugin. Other plugins may want to know the "full" args, so filtering in the IADM is too early. Only for the purpose of clang do we want to filter this out.

depend on new KMime

bumb PIM_VERSION

Done, I presume you'll merge that into master?

do I need to change anything in the CMakeLists.txt to ensure the up2date kmime is found? or are these repos all implicitly depending on each other anyways?

And btw: I'm in favor of the concept, i.e. to use canonical paths everywhere. I've run into issues myself, but I wonder why I'm not seeing the issue you are referencing here. My paths are also containing symlinks. It sounds to me like you are solving a fringe case (i.e. changing paths after the fact). I'm all for handling this gracefully, but to ensure it won't break in the future, we will need a unit test. That will also show us what actually is broken.

please write a unit test

what branch is "stable"? 1.9?

ah ok, and since we don't have a proper byte array view yet, there's nothing you can do (which is sad here!)

+1 if this improves the situation, but in general I was suspecting such issues while reviewing the initial changeset. I suspect we'll see more issues in the future, and I have no clear idea on how to handle that :(

I think the grouping should be moved upstream into the model, too and then be used for file open dialogs to make that visually more similar to what dolphin shows.

it would probably be a good idea to rewrite KConfigGroupPrivate::serializeList to not take a QVariantList, but rather to use a streaming API. I.e. instead of:

The difference you describe between cmake server mode vs. no server mode once again shows that you have not yet fully grasped what's going on here and that this patch as it stands is not the right fix. Find out why the cmake server mode degrades the performance, than fix that. You say:

thanks, lgtm - do you have commit rights?

ok, let's try this out :) What Could Possibly Go Wrong?

could we get a unit test? but otherwise lgtm, minus the one issue I found (sorry :P)

overall lgtm, I'd also like to see some unit test coverage please

sorry for the long delay, has this not been merged yet? I'll try to do this now