Community
Participate
Working Groups
M20110825-0847, follow-up to bug 351165 codeSelect doesn't resolve diamond type arguments for a constructor invocation on the right hand side of a field assignment: package xy; import java.util.Map; public class Try17 { private ThreadLocal<Map<String, Integer>> tl; public void foo() { tl= new ThreadLocal<>(); // should not be ThreadLocal<Object> ThreadLocal<Map<String, Integer>> tl2 = new ThreadLocal<>(); //OK } } The ITypeBinding for the first reference to "new ThreadLocal<>()" is OK, but codeSelect returns a resolved key "Ljava/lang/ThreadLocal<Ljava/lang/Object;>;.()V", where actual type arguments are wrong.
Also happens for local variables, not only for fields: void foo() { HashMap<String, String> map = new HashMap<>(); // OK map = new HashMap<>(); // codeSelect returns HashMap<Object, Object> } Problem is visible in ParameterizedGenericMethodBinding#computeCompatibleMethod(MethodBinding, TypeBinding[], Scope, InvocationSite), where the invocationSite doesn't have an typeExpected in the second case. In the first case, the expected type is set from LocalDeclaration#resolve(BlockScope), but in the second case, the expected type stays null. The cause is an incomplete AST in the codeSelect case. The statements of the MethodDeclaration are: [0]= LocalDeclaration: HashMap<String, String> map; [1]= SelectionOnQualifiedAllocationExpression: <SelectOnAllocationExpression:new HashMap<>()> If I create a DOM AST, the second statement of the MethodDeclaration is: [1]= Assignment: map = new HashMap<>() In that case, "Assignment.resolveType(BlockScope) line: 198" sets the expected type. => I don't know where and why the SelectionParser drops the Assignment node, but that's the reason why the expected type is not available.
This is visible in the UI: The Javadoc hover on the rhs of the assignment shows wrong inferred types for the constructor invocation.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
