Community
Participate
Working Groups
Trying to inline: DirectedExpect addRespExpect( final GlobalTxnRecord txn, final PktNodeInfo fromNode, final PktNodeInfo toNode, final String description, final RoutedPacket pkt, final BitVector matchBits, final BitVector checkBits, final PacketHandler destHandler) { final DirectedExpect expect = new DirectedExpect(expectMgr, txn, fromNode, toNode, description, pkt, matchBits, destHandler); expect.setCheckPacket(checkBits); expect.activate(); return expect; } into: final PacketHandler srcRespHandler = new PacketHandler() { public void execute(final FullExpect expect, final PacketRecord pktRec) { final GlobalTxnRecord txn = expect.getTxn(); if (pktRec.toNode.contains(txn.tgtNode)) { // ... } else { final DirectedPacket fwdPkt; final PktNodeInfo localTgtNode; final BitVector matchBits; // ... addRespExpect(txn, pktRec.toNode, localTgtNode, "forwarded source response", fwdPkt, matchBits, null, this); } } }; results in: Error 2005-07-01 15:21:42.842 Internal Error java.lang.reflect.InvocationTargetException at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:327) at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.run(RefactoringWizardDialog2.java:293) at org.eclipse.ltk.ui.refactoring.RefactoringWizard.internalPerformFinish(RefactoringWizard.java:547) at org.eclipse.ltk.ui.refactoring.UserInputWizardPage.performFinish(UserInputWizardPage.java:153) at org.eclipse.ltk.ui.refactoring.RefactoringWizard.performFinish(RefactoringWizard.java:613) at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.okPressed(RefactoringWizardDialog2.java:417) ... Caused by: java.lang.NullPointerException at org.eclipse.jdt.internal.corext.refactoring.code.CallInliner.replaceCall(CallInliner.java:599) at org.eclipse.jdt.internal.corext.refactoring.code.CallInliner.perform(CallInliner.java:471) at org.eclipse.jdt.internal.corext.refactoring.code.InlineMethodRefactoring.checkFinalConditions(InlineMethodRefactoring.java:238) at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:84) at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:114) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:189) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:86) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113) eclipse.buildId=I20050627-1435 java.version=1.5.0_02 java.vendor=Sun Microsystems Inc.
To investigate for 3.1.1.
Trevor, I tried to reproduce the problem using the test case below and generated stubs for the additional types. However, I was not able to produce the NPE. Do you still have the code around. Can you provide the complete code of the else part of the outer if statement that contains the call to addRespExpect. There must be something that got replaced by //... that causes the refactoring to misinterpret the context. package p102534; public class TestCase { private Manager expectMgr; DirectedExpect addRespExpect( final GlobalTxnRecord txn, final PktNodeInfo fromNode, final PktNodeInfo toNode, final String description, final RoutedPacket pkt, final BitVector matchBits, final BitVector checkBits, final PacketHandler destHandler) { final DirectedExpect expect = new DirectedExpect(expectMgr, txn, fromNode, toNode, description, pkt, matchBits, destHandler); expect.setCheckPacket(checkBits); expect.activate(); return expect; } private void testCase() { final PacketHandler srcRespHandler = new PacketHandler() { public void execute(final FullExpect expect, final PacketRecord pktRec) { final GlobalTxnRecord txn = expect.getTxn(); if (pktRec.toNode.contains(txn.tgtNode)) { // ... } else { final DirectedPacket fwdPkt= null; final PktNodeInfo localTgtNode= null; final BitVector matchBits= null; // ... addRespExpect(txn, pktRec.toNode, localTgtNode, "forwarded source response", fwdPkt, matchBits, null, this); } } }; } }
I think I found it. Could it be that there was a label in front of the addRespExpect call ?
The full fix is too risky for 3.1.1. The problem is that not all statements can be labeled. For example a local declaration can't be labeled. The fix for 3.1.1 will be to introduce a block like in other control statements that can have a single statement as a body.
Created attachment 24543 [details] Code patch
Created attachment 24544 [details] Additional test resources
Created attachment 24545 [details] Additional test methods
Fix reviewed by Martin Aeschlimann and Tom Eicher. Fix released for 3.1.1. Opened PR 105168 to track the issue in the 3.2 stream.
Added two additional test cases TestLabelOne and TestLabelTwo.
start verifying...
verified in I20050808-2000 (3.2) and M20050804-1200 (3.1.1)
