Bug 144426 - [compiler] Compiler incorrectly reports "assignment to variable has no effect" when it is a duplicate
Summary: [compiler] Compiler incorrectly reports "assignment to variable has no effect...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2.1   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-30 08:54 EDT by Fares Abdullah CLA
Modified: 2006-09-11 10:28 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Fares Abdullah CLA 2006-05-30 08:54:51 EDT 
Eclipse 3.2RC4 for Win23: eclipse-SDK-3.2RC4-win32.zip
Running on Windows XP SP2

public class Test {
	public static void main(String[] args) {
		int x = 2;
		if (true) {
			int x = 4;
		}
	}
}

"x = 4" is underlined with multiple markers: "The assignment to variable x has no effect", and "Duplicate local variable x".

I believe that the first one is incorrect ("has no effect").
Comment 1 Philipe Mulet CLA 2006-05-31 06:03:02 EDT 
Reproduced in latest. This is a case where the local binding is null (since duplicate) and no binding is extracted for the right hand side expression, which makes it (incorrectly) think of null==null then has no effect.
Comment 2 Philipe Mulet CLA 2006-05-31 07:21:41 EDT 
Added LocalVariableTest#test011-012.

Releasing fix for 3.2.1.
Comment 3 Frederic Fusier CLA 2006-06-12 05:24:15 EDT 
Released for 3.2.1
Released for 3.3 M1 while merging TARGET_321 in HEAD
Comment 4 Markus Keller CLA 2006-06-12 09:41:10 EDT 
I guess this fix made our RenameTempTests#testFail32() fail.

However, the new behavior is much better than the old (duplicate local variable declarations introduce separate ILocalVariables, and references always map to the most recently declared variable).

I removed the obsolete testFail32() and added a regression tests for the new behavior in HEAD.

NOTE: I don't see the fix in the R3_2_maintenance stream so far, so I think this bug should not yet be marked as fixed in 3.2.1. When the fix is released to the 3.2.1 branch, we also need to adapt the jdt.ui test to avoid the same failure.
Comment 5 Frederic Fusier CLA 2006-06-12 10:29:38 EDT 
Markus,

TARGET_321 is currently our 3.2.1 maintenance stream as R3_2_maintenance is frozen until 3.2.0 is declared. When done, TARGET_321 stream will be merged in R3_2_maintenance one and we will be back to "normal".

So, if you want to get current 3.2.1 fixes, you need to import TARGET_321 branch of org.eclipse.jdt.core project in your workspace...
Comment 6 Markus Keller CLA 2006-06-12 11:08:21 EDT 
OK, sorry for the confusion. Our test failure does not occur with TARGET_321, although I can confirm that this bug is fixed in that branch.

I now guess our test failure was caused by the fix for 144858, which is only for 3.3M1.
Comment 7 Frederic Fusier CLA 2006-08-08 06:56:42 EDT 
Verified for 3.3 M1 using build I20060807-2000.
Comment 8 David Audel CLA 2006-09-11 10:28:54 EDT 
Verified for 3.2.1 using build M20060908-1655