fix concurrent use of AbstractTextSearchResult.fMatchEvent #992

[jukzi]

Some search results where missing when the same object was concurrently passed to listeners. There is no point to reuse the instance.

#992

[merks]

I'm really happy to see changes for this!

[github-actions]

Test Results

 1 821 files  ±0   1 821 suites  ±0   1h 30m 37s ⏱️ -4s
 7 902 tests ±0   7 674 ✅ +1  228 💤 ±0  0 ❌  - 1 
23 793 runs  ±0  23 045 ✅ +1  748 💤 ±0  0 ❌  - 1 

Results for commit c6700b2. ± Comparison against base commit 6e8dd1a.

♻️ This comment has been updated with latest results.

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

bundles/org.eclipse.search/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From 6ec0ecb09d004c7b6d2c789d16f48cdb11c9d47c Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <[email protected]>
Date: Wed, 12 Mar 2025 07:30:24 +0000
Subject: [PATCH] Version bump(s) for 4.36 stream


diff --git a/bundles/org.eclipse.search/META-INF/MANIFEST.MF b/bundles/org.eclipse.search/META-INF/MANIFEST.MF
index 831eb9da3a..73ffbc268a 100644
--- a/bundles/org.eclipse.search/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.search/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.search; singleton:=true
-Bundle-Version: 3.17.100.qualifier
+Bundle-Version: 3.17.200.qualifier
 Bundle-Activator: org.eclipse.search.internal.ui.SearchPlugin
 Bundle-ActivationPolicy: lazy
 Bundle-Vendor: %providerName
-- 
2.48.1

Further information are available in Common Build Issues - Missing version increments.

[iloveeclipse]

From my POV this PR is OK to merge.
@akurtakov : I saw I've merged some PR's from Jörg, how did you avoided the error with eca?
Just ignore it?

[akurtakov]

Some PRs don't fail ECA eclipse-platform/eclipse.platform.releng.aggregator#2510 so I guess it's smth related with Joerg change of email in eclipse account. As the PR had valid ECA but now doesn't I really have no clue what should be done. I'm leaving it to the "collective" knowledge to decide.

[iloveeclipse]

@waynebeaton : I guess you've had such case: the PR was set at the time the PR author (@jukzi) worked for a company X, using company X mail account. Now PR author is not working anymore for the X company. The email is still mentioned in commit metadata.

Considering the fact that at the moment of PR creation ECA check was green, I assume we are OK to merge from the legal point of view.

However, I fear the tooling might complain after the merge?

Should we simply rewrite commit metadata & push it with different (e.g. mine) author reference? Or can we merge?

[waynebeaton]

Considering the fact that at the moment of PR creation ECA check was green, I assume we are OK to merge from the legal point of view.

Correct.

Whether or not the tool will complain... I don't know. But if you can merge, then you should be good-to-go. AFAIK, there's no automatic checks after merge.

When we do one of our periodic checks (that we usually just do quietly), we will detect that the author was covered by an ECA (probably an MCCA based on the scenario) at the time

[iloveeclipse]

Thanks @waynebeaton for a quick response!