Community
Participate
Working Groups
Created attachment 254092 [details] Test projects Using Eclipse 4.5-I20150602-2000. I have a plugin in my workspace that calls javax.xml.validation.Validator.validate. If I use Find references in workspace (Ctrl-shift-G) it does not find many of the references. The fact that it can't find them seems to be dependent on the presence of other code in other plugins. I have attached two projects to illustrate the problem. 1. Extract the zip 2. Import testPlugin project 3. Import testReferences project 4. Open Main.java class in testReferences project 5. Click on the validate call 6. Right-click, References, Workspace. Or Ctrl-shift-G. The workspace reference is not in the results. If you close the testPlugin project, then it works. I also tested that this work in Eclipse 4.4.2 so this is a regression. I also set the severity to Major because I have the feeling that this might affect other methods.
I have bisected jdt.core and found this to be the first commit that introduced the bug: "commit dbfcb8d7fd5ffcddbe22e6b1ba82be9083ee4d44 Author: Manoj Palat <manpalat@in.ibm.com> 2014-10-29 04:04:11 Committer: Manoj Palat <manpalat@in.ibm.com> 2014-10-29 04:04:11 Branches: master, origin/BETA_JAVA9, origin/master, origin/sasikanth/sasi_bug405778, origin/sherrmann/ExternalAnnotations Tags: I20141029-0800, I20141029-2000 Fix for Bug 431357 [search] Search API got wrong result, when searching for method references, where the parameter is a member type of another type. "
*** Bug 464645 has been marked as a duplicate of this bug. ***
(In reply to Marc-Andre Laperle from comment #1) > I have bisected jdt.core and found this to be the first commit that > introduced the bug: > > Fix for Bug 431357 [search] Search API got wrong result, when searching Thanks Marc-Andre. Will take a look.
Note: Root cause found to be sharing of binding lookup across the projects - For every project an LE is initialized and BTB type id would be specific to LE - This gets shared across the projects which causes TypeBinding.equalsEquals to fail due to different type ids and thus the equivalentMatch would fail if there was an entry there in the binding table already even though the types are actually equivalent. Reinit of ML.binding causes this issue to go away. Fix under investigation.
New Gerrit change created: https://git.eclipse.org/r/51085
Gerrit change https://git.eclipse.org/r/51085 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=6908063eba8a685f56d7ca33afe706e68d2c77b5
(In reply to Eclipse Genie from comment #6) > Gerrit change https://git.eclipse.org/r/51085 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=6908063eba8a685f56d7ca33afe706e68d2c77b5 Marc: Can you please check with one of the nightly builds [that includes this commit]? Thanks.
(In reply to Manoj Palat from comment #7) > Marc: Can you please check with one of the nightly builds [that includes > this commit]? Thanks. I tested N20150702-0115 and indeed, it fixes the issue. I tested with the two test cases provided in this bug and bug 464645. I also tested the original issue seen in the CDT code base. I'll do more real-world testing when the first integration build is out. Thank you for the fix!
It looks like the R4_5_maintenance has been created: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/?h=R4_5_maintenance Would it be possible to backport the fix? Thanks!
(In reply to Marc-Andre Laperle from comment #8) > I'll do more real-world testing > when the first integration build is out. I tested I20150707-0800 for a while and it worked well.
(In reply to Marc-Andre Laperle from comment #9) > It looks like the R4_5_maintenance has been created: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/?h=R4_5_maintenance > > Would it be possible to backport the fix? Thanks! Thanks a lot Marc for verifying that the fix works. This would be available at 4.5M1 as it and this is 4.5.1 candidate (SR1) as well. Marc: Which version of the tree do you want this to be backported? (Jay is our lead and I will let him answer the query regarding backporting) Jay: Can you please comment on backport?
(In reply to Manoj Palat from comment #11) > Jay: Can you please comment on backport? We can consider back porting to 4.5.1 if it is a recent regression. Back porting to older branches is not possible.
(In reply to Jay Arthanareeswaran from comment #12) > (In reply to Manoj Palat from comment #11) > > Jay: Can you please comment on backport? > > We can consider back porting to 4.5.1 if it is a recent regression. Back > porting to older branches is not possible. Thanks Jay. This is a recent "issue". I am not saying this is a regression because this issue existed earlier but was brought into light by a recent fix - That fix as such will not change anyway. So will target the SR1 - 4.5.1 branch for backport.
+1 for 4.5.1.
New Gerrit change created: https://git.eclipse.org/r/52758
Gerrit change https://git.eclipse.org/r/52758 was merged to [R4_5_maintenance]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=1e67b69a4e26c9f884bed13126abbad62ee85725
(In reply to Eclipse Genie from comment #16) > Gerrit change https://git.eclipse.org/r/52758 was merged to > [R4_5_maintenance]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=1e67b69a4e26c9f884bed13126abbad62ee85725 Backported to 4.5.1 as well. Moving to resolved
Verified for 4.6 M1 with build I20150803-2000.
Verified for 4.5.1 using M20150819-1000 build
*** Bug 372709 has been marked as a duplicate of this bug. ***
