Summary: | [search] InvocationTargetException on Rename | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Benjamin Pasero <ENJ> | ||||
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | markus.kell.r, martinae | ||||
Version: | 3.1 | ||||||
Target Milestone: | 3.1 RC1 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Benjamin Pasero
2005-05-10 11:58:10 EDT
Created attachment 20886 [details]
Error Log
Markus, can you investigate? Is this a special case or should this be a M7 candidate? 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. 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. 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? This only happens when you have duplicate methods and try to refactor the second one. RC1 is fine with me. OK, thanks 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 Verified in I20050526-2000 |