Summary: | [search] search for reference is broken 2.1 M5 | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Gunnar Wagenknecht <gunnar> |
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | ||
Version: | 2.1 | ||
Target Milestone: | 2.1 RC1 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Gunnar Wagenknecht
2003-02-13 02:59:48 EST
If I select the method and select "Open Super Implementation" it correctly opens the abstract method declaration. If I do the search with the abstract declaration the reference in the hierarchy are found. If I redo this with the overwritten method, nothing is found again. Moving to JDT/Core for comments since the bug is gone when using a fresh workspace. Gunnar, can you provide exact steps which reproduce ? If indexes were faulty, then forcing to recreate them would likely solve this issue (add a space to offending unit, and save it again would cause it to be reindexed). No I can't. I did a full rebuild of all projects and the problem is still there. I tried to reproduce it creating a new workspace but it was impossible. I'm willing to provide my current workspace for testing only if it is reproducable tomorrow but there must be a secure location which is not public visible where I can upload it. It is several MBs large. Rebuilding the projects has no incidence on our indexes. Indexes are updated on actual compilation unit changes. One more thing to try is to exit, flush the index files from the .metadata (under <workspace location>/.metadata/.plugins/org.eclipse.jdt.core/, remove all *.index files - and these only), then restart Eclipse. Ok will try it, but I'm already at home (GMT +0200 :) Deleting indexes had no effect. It might be a problem with abstract methods. I investigate to find a reproducable test case. I've created a 5MB workspace where the problem is repeatable. Can I upload it somewhere or send it by Email? 5MB is quite big, we don't have a public ftp site on Eclipse server. If you posted it somewhere we can access it by ftp, this would be perfect. Your last comment sounds like this isn't an indexing problem. Our search engine (looking at indexes and refining match locations) seems to be the offending piece here. Note that we had a regression in M5 around abstract methods, which we have resolved since then. Did you try the patch posted on the JDT/Core page ? http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/r2.1/main.html#updates or direct link to the patch: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/patches/org.eclipse.jdt.core_2.1.0.zip Also, given indexes are not guilty, maybe you could simply attach a few source files to this PR so as to reproduce the problem (with detailed setup). The problem seems not to be repeatable with a simple set of source files. I tried copying all together and the error was gone. It seems that it only occurs if the source is splitted into different projects. Thanks for all your efforts Gunnar. I was able to reproduce the problem with your workspace and I'm investigating right now. Simple test case: 1. Create Java project Test1 2. Add X.java in package p in Test1: package p; public class X { protected void foo() { } void bar() { foo(); } } 3. Create project Test2 that prereqs Test1 4. Add Y.java in Test2: import p.X; public class Y extends X { protected void foo() { } } 5. Select Y.foo and search for references in hierarchy Observe: None is found You are welcome. Thank you for producing a simple test case. In the case of a polymorphic search, the IndexSelector was not inluding the indexes of the prereq projects and jars. Fixed and added regression test JavaSearchTests.testHierarchyScope2() Reopening as fixing the simple test case doesn't fix the problem in Gunnar's workspace. Test case that is closer to Gunnar's workspace: 1. Create Java project Test1 2. Add X.java in package p in Test1: package p; public class X { protected void foo() { } void bar() { foo(); } } 3. Create project Test2 that prereqs Test1 4. Add Y.java in Test2: import p.X; public class Y extends X { } 5. Add Z.java in Test2: public class Z extends Y { protected void foo() { } } 6. Select Z.foo and search for references in hierarchy Observe: None is found Finally got it right! When searching in the hierarchy, all potential matches are now resolved in the context of the focus type's project. Verified it works with Gunnar's workspace and added regression test JavaSearchTests.testHierarchyScope3() Verified. Moved the 2 tests to JavaSearchMultipleProjectsTests.testHierarchyScope1() and testHierarchyScope2() |