Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 330169

Summary:

[refactoring] Extract method throws NPE if declared lifting arg is involved

Product:

[Tools] Objectteams

Reporter:

Stephan Herrmann <stephan.herrmann>

Component:

OTDT

Assignee:

Stephan Herrmann <stephan.herrmann>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

Version:

0.8

Target Milestone:

0.8 M4

Hardware:

Other

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
test & fix	none

Description Stephan Herrmann

2010-11-13 10:05:14 EST

If an extract method refactoring affects an argument with a declared
lifting type, the refactoring throws the following exception:

java.lang.NullPointerException
	at org.eclipse.jdt.internal.corext.dom.Selection.covers(Selection.java:133)
	at org.eclipse.jdt.internal.corext.refactoring.code.ExtractMethodAnalyzer.removeSelectedDeclarations(ExtractMethodAnalyzer.java:494)
	at org.eclipse.jdt.internal.corext.refactoring.code.ExtractMethodAnalyzer.computeInput(ExtractMethodAnalyzer.java:484)
	at org.eclipse.jdt.internal.corext.refactoring.code.ExtractMethodAnalyzer.analyzeSelection(ExtractMethodAnalyzer.java:357)
	at org.eclipse.jdt.internal.corext.refactoring.code.ExtractMethodAnalyzer.checkInitialConditions(ExtractMethodAnalyzer.java:207)
	at org.eclipse.jdt.internal.corext.refactoring.code.ExtractMethodRefactoring.checkInitialConditions(ExtractMethodRefactoring.java:297)
	at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:83)



This was observed while working on
   OTQuickFixes.registerNewMethodCorrectionProposal(..)
and has been reproduced in ExtractMethodTests.testDeclaredLifting1()

Additionally, if no local variables are declared this exception may be 
thrown:

java.lang.ArrayIndexOutOfBoundsException: 1
	at org.eclipse.jdt.internal.corext.refactoring.code.flow.LocalFlowInfo.<init>(LocalFlowInfo.java:24)
	at org.eclipse.jdt.internal.corext.refactoring.code.flow.FlowAnalyzer.endVisit(FlowAnalyzer.java:766)
	at org.eclipse.jdt.core.dom.SimpleName.accept0(SimpleName.java:152)
	at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2615)
	at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2663)
	at org.eclipse.jdt.core.dom.MethodInvocation.accept0(MethodInvocation.java:240)
	at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2615)
	at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2663)
	at org.eclipse.jdt.core.dom.ExpressionStatement.accept0(ExpressionStatement.java:144)
	at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2615)
	at org.eclipse.jdt.internal.corext.refactoring.code.flow.InOutFlowAnalyzer.perform(InOutFlowAnalyzer.java:40)
	at org.eclipse.jdt.internal.corext.refactoring.code.ExtractMethodAnalyzer.analyzeSelection(ExtractMethodAnalyzer.java:335)
	at org.eclipse.jdt.internal.corext.refactoring.code.ExtractMethodAnalyzer.checkInitialConditions(ExtractMethodAnalyzer.java:207)
	at org.eclipse.jdt.internal.corext.refactoring.code.ExtractMethodRefactoring.checkInitialConditions(ExtractMethodRefactoring.java:297)

Comment 1 Stephan Herrmann

2010-11-14 10:04:58 EST

Created attachment 183094 [details]
test & fix

Several locations didn't respect the fact that an argument with declared
lifting is mapped to two variables internally (arg + local), because the
lifting local variable declaration is marked as generated and thus not
converted to DOM AST.

Resolved by the following steps:
+ DefaultBindingResolver registers both variables, creating a faked
  SingleVariableDeclaration for the hidden local, yet binding this to
  the existing compiler binding.
+ LocalVariableIndex respects lifting args with the help of
  + new role DOMAdaptor.LocalVariableIndex
  + new method VariableBinding.getVariableIdMax()
+ JDT/UI's ASTFlattener is adapted for flattening declared lifting

Note, that the problem in LocalVariableIndex was easily masked if the 
method declares real local variables with higher IDs than the lifting arg.

Comment 2 Stephan Herrmann

2010-11-14 10:07:13 EST

Committed as r1029 ff.

Comment 3 Stephan Herrmann

2010-11-15 16:04:10 EST

Verified for M4 using build 201011141250.