Community
Participate
Working Groups
I200411231600 with ZRH plug-in export from 20041124_0833 The method I wanted to inline had the signature (String, Method[]) but the arguments where (String, Constructor[]) (causing a compile error) and using Goto Declaration resolved to the overloading method with signature (Method[]). java.lang.reflect.InvocationTargetException at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:303) at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.run( RefactoringWizardDialog2.java:282) at org.eclipse.ltk.ui.refactoring.RefactoringWizard.internalPerformFinis h(RefactoringWizard.java:539) at org.eclipse.ltk.ui.refactoring.UserInputWizardPage.performFinish(User InputWizardPage.java:153) at org.eclipse.ltk.ui.refactoring.RefactoringWizard.performFinish(Refact oringWizard.java:605) at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.okPr essed(RefactoringWizardDialog2.java:406) at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:396) at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:543) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java: 89) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:818) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2803) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2448) at org.eclipse.jface.window.Window.runEventLoop(Window.java:718) at org.eclipse.jface.window.Window.open(Window.java:696) at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation$1.run(R efactoringWizardOpenOperation.java:125) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69) at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation.run(Ref actoringWizardOpenOperation.java:138) at org.eclipse.jdt.internal.ui.refactoring.actions.RefactoringStarter.ac tivate(RefactoringStarter.java:40) at org.eclipse.jdt.internal.ui.refactoring.actions.InlineMethodAction.ac tivate(InlineMethodAction.java:170) at org.eclipse.jdt.internal.ui.refactoring.actions.InlineMethodAction.ru n(InlineMethodAction.java:163) at org.eclipse.jdt.internal.ui.refactoring.actions.InlineMethodAction.ru n(InlineMethodAction.java:141) at org.eclipse.jdt.ui.actions.InlineAction.tryInlineMethod(InlineAction. java:146) at org.eclipse.jdt.ui.actions.InlineAction.run(InlineAction.java:116) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(Select ionDispatchAction.java:216) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispa tchAction.java:188) at org.eclipse.jface.action.Action.runWithEvent(Action.java:989) at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:188) at org.eclipse.ui.internal.commands.Command.execute(Command.java:130) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(Workben chKeyboard.java:445) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboar d.java:724) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(Workbe nchKeyboard.java:767) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindi ngs(WorkbenchKeyboard.java:536) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$2(WorkbenchKeyb oard.java:479) at org.eclipse.ui.internal.keys.WorkbenchKeyboard$1.handleEvent(Workbenc hKeyboard.java:221) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:752) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:817) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:842) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:827) at org.eclipse.swt.widgets.Control.traverse(Control.java:2696) at org.eclipse.swt.widgets.Control.translateMnemonic(Control.java:2537) at org.eclipse.swt.widgets.Composite.translateMnemonic(Composite.java:78 6) at org.eclipse.swt.widgets.Control.translateMnemonic(Control.java:2555) at org.eclipse.swt.widgets.Display.translateMnemonic(Display.java:3223) at org.eclipse.swt.widgets.Display.filterMessage(Display.java:766) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2444) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1573) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1544) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.jav a:279) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:144) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:10 2) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformAct ivator.java:220) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja va:273) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja va:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:185) at org.eclipse.core.launcher.Main.run(Main.java:710) at org.eclipse.core.launcher.Main.main(Main.java:694) Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1 at java.util.ArrayList.RangeCheck(ArrayList.java:507) at java.util.ArrayList.get(ArrayList.java:324) at org.eclipse.jdt.core.dom.ASTNode$NodeList.get(ASTNode.java:1194) at org.eclipse.jdt.internal.corext.refactoring.code.SourceProvider.getPa rameterData(SourceProvider.java:207) at org.eclipse.jdt.internal.corext.refactoring.code.CallInliner.computeR ealArguments(CallInliner.java:460) at org.eclipse.jdt.internal.corext.refactoring.code.CallInliner.initiali ze(CallInliner.java:263) at org.eclipse.jdt.internal.corext.refactoring.code.InlineMethodRefactor ing.checkFinalConditions(InlineMethodRefactoring.java:228) at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckCo nditionsOperation.java:84) at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChan geOperation.java:114) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformCh angeOperation.java:188) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1676 ) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run( WorkbenchRunnableAdapter.java:58) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(Modal Context.java:105) Root exception: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1 at java.util.ArrayList.RangeCheck(ArrayList.java:507) at java.util.ArrayList.get(ArrayList.java:324) at org.eclipse.jdt.core.dom.ASTNode$NodeList.get(ASTNode.java:1194) at org.eclipse.jdt.internal.corext.refactoring.code.SourceProvider.getPa rameterData(SourceProvider.java:207) at org.eclipse.jdt.internal.corext.refactoring.code.CallInliner.computeR ealArguments(CallInliner.java:460) at org.eclipse.jdt.internal.corext.refactoring.code.CallInliner.initiali ze(CallInliner.java:263) at org.eclipse.jdt.internal.corext.refactoring.code.InlineMethodRefactor ing.checkFinalConditions(InlineMethodRefactoring.java:228) at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckCo nditionsOperation.java:84) at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChan geOperation.java:114) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformCh angeOperation.java:188) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1676 ) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run( WorkbenchRunnableAdapter.java:58) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(Modal Context.java:105)
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
