@rjvbb Hi, please Abandon this review, as the reply has been that this should be solved on KDE Frameworks level, in KAboutData (as well as with respective new ECM module for getting the VCS/git revision info into the buildsystem).

@rjvbb Hi, please use the "Abandon this Revision" action, given that this patch/feature was not accepted, so the list of patches to review is not cluttered for everyone.

@tristanp Hi. You do not have push rights for KDE code reposistories, correct? So someone else would need to push for you then. Okay to extend your author name in the commit message to "Tristan Porteries"?

In D22182#492046, @aaronpuchert wrote:

I don't find it terribly verbose. Also there are other locks used in the du-chain code, and I think it doesn't hurt to be a little bit more explicit.

In D22182#491716, @mswan wrote:

I don't suspect our ..Locker constructors will ever (i.e. not anytime prior to the heat death of the universe) take a different lock. For that reason I am partial to making the lock implicit wherever possible.

That's a bold statement. ;)

In D22182#491022, @aaronpuchert wrote:

If we make the lock explicit, we can just annotate the constructor with ACQUIRE[_SHARED](duChainLock) (using the macros from the docs).

In D22158#491427, @kossebau wrote:

Not sure yet about all color mappings, that might need some more thinking, at least on a quick test across themes that resulted in quite some unreadable variants. Will play a bit during the upcoming WE.

Interesting approach, might work out, thanks for doing this :)

In D22182#490537, @mswan wrote:

I have actually tried changing my experiment with clang's thread safety to use the scoping feature and I seem to be seeing a new issue with these destructors with an error like "lock using shared access, expected exclusive access."

EDIT: I have come across your oldish ticket regarding this: https://bugs.llvm.org/show_bug.cgi?id=33504. Evidently I need to annotate my DUChainReadLocker releasing functions with RELEASE(..) instead of RELEASE_SHARED(..). Not sure I understand why.

I think this DUChain::lock() probably still needs to be exposed as a variable or perhaps it needs to be annotated some way because I suspect that clang is not going to figure out that every value returned from this function is the exact same lock. If I start adding annotations to functions that expect the effectively global DUChain lock to be held beforehand, I would have to write something like REQUIRES(DUChain::lock()) which as I said likely doesn't do what I want.

In D22182#490536, @aaronpuchert wrote:

Hmm, you're right. Maybe we can get rid of that when we're certain through static checking that this isn't needed anymore.

Well at least the destructor will need that behaviour because it is certainly sane behaviour for someone to unlock a lock somewhere along the line and then leave it unlocked till the end of the function, e.g. the code I included with this ticket. There didn't seem to be a way that I could scope that lock because this lock was needed for a local constructor invocation.

In D22182#490534, @mswan wrote:

I agree, but in the current implementation they are see DUChainReadLocker::lock() and DUChainReadLocker::unlock(), they both check if we are already locked before continuing to lock or unlock respectively.

So it might make sense to try to refactor this DUChain locking abstraction entirely and possibly change all call-sites to respect the new interface. The first obvious question is how do you make this locker thing achieve the same end. It is somewhat convenient that the destructor idempotent behaviour is the way it is. I don't want to invoke lock.lock() at the end of every function to satisfy that destructor and I also wouldn't want to get rid of that destructor behaviour.

In D22182#490533, @aaronpuchert wrote:

Lock and unlock shouldn't be idempotent.

In D22182#490532, @mswan wrote:

Interesting. I have experimented with this a bit and I cannot find a way to articulate to the thread safety system that my lock and unlock functions are idempotent. If I call lock.unlock() and later return without locking it again, I get a warning (or rather an error because I set -Werror=thread-safety) that complains that I am releasing a lock that isn't held. So would -Wno-error=thread-safety-negative allow us to get around that or is there possibly some other solution?

In D22182#490522, @aaronpuchert wrote:

In D22182#489873, @mswan wrote:

This should definitely be tried and I would be interested in the task. There is definitely quite alot of stuff that needs to be annotated to make this work so it might need several hands working on it.

I'd be delighted and would happily work with you on this. I worked on the Thread Safety Analysis feature for a while.

The one problem with adopting that system in KDevelop is that we copy DUChain::lock() into each instance of DUChain{Read,Write}Locker which means that our annotations wouldn't see the DUChainReadLocker in one instance as the same lock in another instance.

I don't think the lock is copied, it's just a pointer to it. That's not an issue, std::lock_guard does that as well. Note that DUChainLock would be annotated with __attribute__((capability("mutex"))), but DUChainReadLocker with __attribute__((scoped_lockable)). The analysis tracks which scoped capability owns which capability.

Since I have never seen DUChain{Read,Write}Locker used with anything other than DUChain::lock()

Wondered about this as well—the constructor allows specifying any lock, but this is used only with DUChain::lock().

this shouldn't be cause for false positive deadlock detection.

Deadlock detection needs to turned on separately anyway. (With -Wthread-safety-negative, because it requires "negative capabilities", i.e. someone not having a lock as opposed to having it.)

I wouldn't worry too much about that for now.

In D22182#489873, @mswan wrote:

This should definitely be tried and I would be interested in the task. There is definitely quite alot of stuff that needs to be annotated to make this work so it might need several hands working on it.

In D22182#489868, @aaronpuchert wrote:

I looked through all of the paths to the failed assertion discussed in that latter ticket and it appears that all but the invocation in PotentialBuddyCollector::accept is verified to have the reader lock held prior to invocation. There were two paths which needed a lock added given my change, so this change set should not cause any regression on bug #386901.

I've always wondered whether Clang's Thread Safety Analysis could be of any help in KDevelop, perhaps it is.

I looked through all of the paths to the failed assertion discussed in that latter ticket and it appears that all but the invocation in PotentialBuddyCollector::accept is verified to have the reader lock held prior to invocation. There were two paths which needed a lock added given my change, so this change set should not cause any regression on bug #386901.

Work with gcc, still have a few failing tests to investigate.

Upload from arc to get everything filled out.

• Rename m_xxxHighlight to xxxHiglight as they are public.

Add now necessary locks to avoid recurrence of bug 386901.

Patch looks good to me. Would you be able to offer screenshots using Breeze?

Please clean the patch of whitespace changes.

Indeed Gitlab should simplify things a lot.

In D21156#486870, @kfunk wrote:

Oh, I usually squash my changes into the original commit before uploading the change (i.e. via arc diff). I do not use an extra branch either.

Phew. Anyhow. Let me sum this all up with: Please make your life easier and rather start using KDE's GitLab instance: It's much easier to use since it shares the same workflow as all other major Git hosting platforms out there: https://invent.kde.org/kde/kdevelop

Phabricator is just horrible to adapt to and integrates badly with the usual Git workflow. For KDE development, Phabricator will likely be displaced by GitLab anyway in near future.

Oh, I usually squash my changes into the original commit before uploading the change (i.e. via arc diff). I do not use an extra branch either.

In D21156#486838, @kfunk wrote:

Huh? It's easier than that:

• If you do not have the commit yet locally:
  
  ` arc patch --nobranch <ID> git push `

Or probably a simpler approach is to run these two commands irregarding the fact that I have the commits locally or not. So I just pull the 'clean' modification with the correct commit message and then push to a target branch. E.g: git push origin 5.3

• If you do have the commit and it is the latest one in your history: ` arc amend git push `

Sorry but it is still not clear if this would work. In this diff I have three commits (modification_1, modification_2, revert modifications_2) in a feature branch forked from master. I need to push to 5.3. If I run those two commands I expect that three commits are pushed (not a single one with the total modification) and I would expect that those are pushed to origin/my-feature-branch not in 5.3. Isn't it?

> I suggest to do a `arc amend` (to basically update the commit message with current reviewers, "Differentiatl Revision" line, etc.) and then `git push` your change manually to the right branch. Let's you use your normal git command-line to actually push changes, which to me is a much more thrust-worthy approach than to rely on arc to do that for me...

Probably this should be added to the guide. And probably it should also be added that the commits should be squashed (thing that `arc land` does automatically).

Huh? It's easier than that:

Wouldn't make more sense to do arc land --onto 5.3 (and then merge 5.3 into master)? In this way the Differential Revision would be closed automatically.

I suggest to do a arc amend (to basically update the commit message with current reviewers, "Differentiatl Revision" line, etc.) and then git push your change manually to the right branch. Let's you use your normal git command-line to actually push changes, which to me is a much more thrust-worthy approach than to rely on arc to do that for me...

In D21156#486774, @simgunz wrote:

In the phabricator guide it is suggested to push manually when the target branch in not master:

https://community.kde.org/Infrastructure/Phabricator#Landing_on_the_.22Stable_branch.22

In D21156#486774, @simgunz wrote:

In D21156#486717, @aacid wrote:

If you're not using arc you should have included the "Differential Revision" line in the commit so it would close automatically as stated in https://community.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages

I'll close this manually for you :)

In the phabricator guide it is suggested to push manually when the target branch in not master:

https://community.kde.org/Infrastructure/Phabricator#Landing_on_the_.22Stable_branch.22

Wouldn't make more sense to do arc land --onto 5.3 (and then merge 5.3 into master)? In this way the Differential Revision would be closed automatically.

In D21156#486717, @aacid wrote:

If you're not using arc you should have included the "Differential Revision" line in the commit so it would close automatically as stated in https://community.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages

I'll close this manually for you :)

If you're not using arc you should have included the "Differential Revision" line in the commit so it would close automatically as stated in https://community.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages

I have pushed to 5.3 and then merged to master manually, as specified in the Phabricator page guide. How do I close the revision now?

lgtm, thanks - do you have commit rights? if so, please push to the 5.3 branch

ScriptErrorFilteringStrategyFix: all the items where set as InformativeItem even when there were no matches

This patch adds some patterns to ScriptErrorFilterStrategy to handle some PHP errors so that you can click on the message and the matching file is opened.

• Document feature

I reverted the commit were the Ctrl feature was disabled, going back to the first fix I proposed

In D18758#481378, @arrowd wrote:

R32:bd048e67f056b5be25ed57fb2be947444f68c24e

In D18758#481339, @mwolff wrote:

so, I've now committed an alternative fix (or so I hope...) see:

commit bd048e67f056b5be25ed57fb2be947444f68c24e
Author: Milian Wolff <mail@milianw.de>
Date:   Mon Jun 17 22:26:32 2019 +0200

    Guard against crashes when IStatus object gets destroyed at bad times

I confirm this fixes the issue for me. Yay, thanks!

In D18758#481339, @mwolff wrote:

so, I've now committed an alternative fix (or so I hope...) see:

commit bd048e67f056b5be25ed57fb2be947444f68c24e
Author: Milian Wolff <mail@milianw.de>
Date:   Mon Jun 17 22:26:32 2019 +0200

    Guard against crashes when IStatus object gets destroyed at bad times

having looked at the raw diff quickly, I like what I'm seeing. What boilerplate are you referring to?

so, I've now committed an alternative fix (or so I hope...) see:

ok, sorry for the rabbit hole I sent you down. I still think that long-term we will need something like QPromise, but phabricator doesn't even let me view the interesting changes in shell/... so I cannot comment on the boilerplate

In D21156#466636, @simgunz wrote:

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

As rjvbb said, no feature have been removed. The feature is still there through the Alt key (as it was before), while not accessible anymore with the Ctrl key. There is no reason to have the same (undocumented) feature on two different keys. Moreover there is no code to cleanup, what is there is needed to have the feature working on the Alt key (at least for my understanding of the code, I have not noticed unuseful blocks).

In D21580#481264, @kossebau wrote:

This sadly seems to have broken navigating with the "Next item"/"Previous item" actions for me. Please give this a look.

This sadly seems to have broken navigating with the "Next item"/"Previous item" actions for me. Please give this a look.

ping

In D21589#477664, @Petross404 wrote:

brauch is referring to this

for /f "usebackq tokens=3*" %%a in (`reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VS7" /s`) do (
     set vs15_path=%%a %%b
     if exist "!vs15_path!Common7\Tools\VsDevCmd.bat" (
	set "VS150COMNTOOLS=!vs15_path!Common7\Tools\"
	goto :end
     )
   )
)
:end

Oops. What happened here is I was hacking on the release version which looks more like the patch I posted. I'll see if I can make sense of the master branch version and make it more like that!

brauch is referring to this

In D21589#477604, @brauch wrote:

Why did you replace the registry query by a fixed path?

Why did you replace the registry query by a fixed path?

LGTM, maybe @kfunk or @brauch know more?

Missing idx_line

lgtm

In D18758#469623, @apol wrote:

Quite possibly, it doesn't happen outside of tests after all, right?

Works fine for me on Ubuntu 19.04 -- lgtm!

Ping?

Quite possibly, it doesn't happen outside of tests after all, right?

I'm more interested in fixing the intial issue. With KIO jobs in openProject turned async, the crash now happens right in qWait(1) of KDevelop::TestCore::shutdown(). And what's strange is that adding qWait(1) at the end of testReload() test still fixes issue.