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

Bug 355934

Summary:	[1.7] codeSelect doesn't resolve diamond type arguments in variable assignment
Product:	[Eclipse Project] JDT	Reporter:	Markus Keller <markus.kell.r>
Component:	Core	Assignee:	JDT-Core-Inbox <jdt-core-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	amj87.iitr, daniel_megert
Version:	3.7.1
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:	stalebug

Description Markus Keller

2011-08-26 07:04:15 EDT

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.

Comment 1 Markus Keller

2015-12-02 08:41:05 EST

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.

Comment 2 Markus Keller

2015-12-02 08:49:48 EST

This is visible in the UI: The Javadoc hover on the rhs of the assignment shows wrong inferred types for the constructor invocation.

Comment 3 Eclipse Genie

2020-05-09 15:04:11 EDT

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.