NullPointer while trying to extract method about xtext-extras HOT 10 CLOSED

Thanks, this is reproducible.

from xtext-extras.

hi, can you share the producing code snippet as well?

from xtext-extras.

This seems to happen when the "Extract Method" refactoring is performed. The refactoring wants to declare an explicit return type, but the return type reference is null. We have to know under which circumstances this could happen.
Could you share more information about the refactoring context, e.g. the code snippet that you would like to extract to a method? Could this be reproduced with a simple example?

from xtext-extras.

The following code produces the same error when trying to extract a method from the body of test.

import java.util.ArrayList

class Test {
	def void test() {
		val int a = 5
		new ArrayList<Integer>.addAll(#[a])
	}
}

from xtext-extras.

typeComputationServices.getTypeConformanceComputer().getCommonSuperType(returnTypes, owner) of [void, boolean, boolean] is null.

the follow up code does not exepect that

from xtext-extras.

maybe we can do something like

returnType = calculateReturnType(resolvedTypes);
if (returnType == null) {
	StandardTypeReferenceOwner owner = new StandardTypeReferenceOwner(typeComputationServices, xtendClass);
	returnType = owner.newReferenceTo(Void.TYPE);
}

@JanKoehnlein what do you think?

or should the getCommonSuperType be void? @svenefftinge

from xtext-extras.

The proposed change would fix the NPE, but the actual problem is that the return type is not computed correctly. Consider this file:

package test

import java.util.ArrayList
import org.eclipse.xtend.lib.annotations.Data

class Foo {
	Bar thisEnd
	def boolean test() {
		val int a = 5
		val x = '''«thisEnd.name»'''
		return new ArrayList<Integer>.addAll(#[a])
	}
}

@Data
class Bar {
	String name
}

If you extract the two lines val x = ...`` and return ...`, then the refactoring would now determine void as the type. This will lead to a compile error, since the extracted method has a return statement with a type expectation, but it is incompatible with the declared return type void.

from xtext-extras.

For a workaround, how about suppressing the return type declaration and disable the "Explicit declare return type" option in the dialog? Again, this would not fix the actual problem, but should be realizable in reasonable effort and would lead to compilable code.

from xtext-extras.

see #128
and eclipse/xtext-xtend#190

from xtext-extras.

merged the PRs. Thanks everyone for investigation.

from xtext-extras.