Bug 31748 - [search] search for reference is broken 2.1 M5
Summary: [search] search for reference is broken 2.1 M5
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.1 RC1   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-02-13 02:59 EST by Gunnar Wagenknecht CLA
Modified: 2003-03-05 07:00 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gunnar Wagenknecht CLA 2003-02-13 02:59:48 EST
I had a class inherited from another class and I could found any search results 
(neither in the workspace nor in the hierarchy) for overwritten protected 
methods although thay are referenced in the super class.

Could it be a broken index? There is nothing in the log. The classpath is ok. 
There are no compile errors. I tried to reproduce it with a clean workspace but 
it was not possible.

I didn't have this yesterday using M4.
Comment 1 Gunnar Wagenknecht CLA 2003-02-13 03:06:45 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.
Comment 2 Dirk Baeumer CLA 2003-02-13 04:42:07 EST
Moving to JDT/Core for comments since the bug is gone when using a fresh 
workspace.
Comment 3 Philipe Mulet CLA 2003-02-13 12:25:20 EST
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).

Comment 4 Gunnar Wagenknecht CLA 2003-02-13 12:42:18 EST
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.
Comment 5 Philipe Mulet CLA 2003-02-13 12:55:37 EST
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.
Comment 6 Gunnar Wagenknecht CLA 2003-02-13 12:59:55 EST
Ok will try it, but I'm already at home (GMT +0200 :)
Comment 7 Gunnar Wagenknecht CLA 2003-02-14 02:49:28 EST
Deleting indexes had no effect. It might be a problem with abstract methods. I 
investigate to find a reproducable test case.
Comment 8 Gunnar Wagenknecht CLA 2003-02-14 03:37:55 EST
I've created a 5MB workspace where the problem is repeatable. Can I upload it 
somewhere or send it by Email?
Comment 9 Philipe Mulet CLA 2003-02-14 05:37:30 EST
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. 

Comment 10 Philipe Mulet CLA 2003-02-14 05:42:25 EST
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
Comment 11 Philipe Mulet CLA 2003-02-14 05:43:28 EST
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).
Comment 12 Gunnar Wagenknecht CLA 2003-02-14 09:04:01 EST
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.
Comment 13 Jerome Lanneluc CLA 2003-02-14 10:20:38 EST
Thanks for all your efforts Gunnar. I was able to reproduce the problem with 
your workspace and I'm investigating right now.
Comment 14 Jerome Lanneluc CLA 2003-02-14 10:51:28 EST
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

Comment 15 Gunnar Wagenknecht CLA 2003-02-14 14:30:25 EST
You are welcome. Thank you for producing a simple test case.
Comment 16 Jerome Lanneluc CLA 2003-02-16 08:29:07 EST
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()
Comment 17 Jerome Lanneluc CLA 2003-02-17 07:27:00 EST
Reopening as fixing the simple test case doesn't fix the problem in Gunnar's 
workspace.
Comment 18 Jerome Lanneluc CLA 2003-02-17 07:35:06 EST
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
Comment 19 Jerome Lanneluc CLA 2003-02-17 09:25:34 EST
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()
Comment 20 David Audel CLA 2003-02-25 05:48:10 EST
Verified.
Comment 21 Jerome Lanneluc CLA 2003-03-05 07:00:18 EST
Moved the 2 tests to JavaSearchMultipleProjectsTests.testHierarchyScope1() and 
testHierarchyScope2()