Summary: | [search] IOOBE when inlining a method | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Christof Marti <christof_marti> |
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P2 | CC: | dirk_baeumer |
Version: | 3.1 | ||
Target Milestone: | 3.1 M6 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Christof Marti
2004-11-24 08:53:34 EST
Has to wait. This seems to be a problem with the search engine. What happens is that a call with two arguments resolves to a method only having one argument. All the code in inline assumes that the number of arguments are the same except for varargs. Given the following test case public class A { void foo(String s, Method[] methods) { } void foo(Method[] methods) { } void call() { String s= null; Constructor[] constructors= null; foo(s, constructors); } } I tested the following scenario: - comment out foo(Method[] methods) - inline the call to foo. This inlines foo(String s, Method[] methods) due to the fact that searching for references to foo reports the call foo(s, constructors) as an exact match which isn't the case. However I couldn't reproduce the case where the call foo(s, constructors) was mapped to the method foo(Method[] methods). F3 navigates to it when foo(String s, Method[] methods) is commented out however search will not report a match. Moving to Core to comment on the search behaviour in the first scenario. Currently, this problem happens because although message send is invalid, compiler set its binding to the closest valid method binding it is able to find (foo(String,Method[]) in this case). This behavior surely needs to be changed in order to keep alive the fact that the binding is invalid and let users (as search engine) to decide whether closest match can be used or not. However, this change would have impacts on existing behavior (especially for code select) and was too risky to apply just before 3.1 M5 release. Moreover, code is invalid and IOOBE seems to be catched (no dialog, nothing in error log), so user should not be worry about it. For all these reasons, defer fix for this bug to next milestone. Fixed. Now search engine returns potential for found match. Note that there was not necessary to modify the fact that closest method binding was stored in MessageSend binding as in this case its resolvedType is null and allow MethodLocator to identify this specific case. [jdt-core-internal] Changes done in MethodLocator.resolveLevel(MessageSend) Test case added in JavaSearchBugsTests Verified in I20050330-0500 |