Bug 94389 - [search] InvocationTargetException on Rename
Summary: [search] InvocationTargetException on Rename
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 RC1   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-10 11:58 EDT by Benjamin Pasero CLA
Modified: 2005-05-27 10:06 EDT (History)
2 users (show)

See Also:

Attachments
Error Log (6.00 KB, application/octet-stream)
2005-05-10 11:58 EDT, Benjamin Pasero CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Pasero CLA 2005-05-10 11:58:10 EDT 
Version: 3.1.0
Build id: I20050509-2010

Steps to reproduce:
1.) Create a new Class "Foo"
2.) Add two empty Methods "public void foo()" and "public void bar()"
3.) Refactor > Rename Method "bar()" into "foo" ignoring the Warning
4.) Refactor > Rename Method "foo" back to "bar"

Actual Results:
The error log shows an Internal Error (see Attachment)

Expected Results:
-

Regards,
Ben
Comment 1 Benjamin Pasero CLA 2005-05-10 11:58:33 EDT 
Created attachment 20886 [details]
Error Log
Comment 2 Martin Aeschlimann CLA 2005-05-10 13:07:45 EDT 
Markus, can you investigate? Is this a special case or should this be a M7
candidate?
Comment 3 Markus Keller CLA 2005-05-10 13:31:17 EDT 
Strange. After playing around a bit, the duplicated method can be renamed again.
Need to debug. I assume there's some stale working copy lying around.
Comment 4 Markus Keller CLA 2005-05-12 05:46:59 EDT 
Moving to JDT/Core.

This is a problem of the search engine. We search for declarations of foo() in
workspace and get two matches with correct source ranges for the two methods.

However, for both matches, getElement() returns an IMethod with occurrenceCount
1. Expected: the second match's element has occurrenceCount 2.

Caveat: you have to select the second foo() to reproduce this - from the first
foo(), it always works.
Comment 5 Frederic Fusier CLA 2005-05-12 06:48:19 EDT 
Problem comes from handle creation while reporting match. For a method, we get
method from it's parent type using selector and type arguments. As it's a
duplicate  method we get twice the same handle...
Do you need it for M7 or may be done for RC1?
Comment 6 Markus Keller CLA 2005-05-12 08:12:37 EDT 
This only happens when you have duplicate methods and try to refactor the second
one. RC1 is fine with me.
Comment 7 Frederic Fusier CLA 2005-05-12 08:50:53 EDT 
OK, thanks
Comment 8 Frederic Fusier CLA 2005-05-14 15:43:03 EDT 
Fixed and released in HEAD.

Duplicate methods are now correctly handled by search engine.

[jdt-core internal]
Changes done in MatchLocator:
  - add cache allHandleOccurences
  - modify method createHandle(AbstractMethodDeclaration,IJavaElement)
  - add createMethodHandle(...)
  - modify reportMatching(CompilationUnitDeclaration,boolean)

Test case added in JavaSearchBugsTests
Comment 9 Olivier Thomann CLA 2005-05-27 10:06:12 EDT 
Verified in I20050526-2000