Bug 338303

Summary:

[compiler][null] Warning about Redundant assignment conflicts with definite assignment analysis

Product:

[Eclipse Project] JDT

Reporter:

keesvr

Component:

Core

Assignee:

Stephan Herrmann <stephan.herrmann>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

amj87.iitr, stephan.herrmann

Version:

3.7

Target Milestone:

3.7 M6

Hardware:

Macintosh

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

Attachments:

Description	Flags
test & proposed fix	none

Description keesvr

2011-02-26 06:30:55 EST

Build Identifier: 20110218-0911

Given the following function:
----------
   TileClusterCacheEntry getReadonlyCluster(final File f,
            final int zoom, final long clusterNo) {
        TileClusterCacheEntry ce;
        try {
            ce = searchCacheEntry(zoom, clusterNo);
            if (ce == null) {
                ce = loadEntry(f, zoom, clusterNo, false);
            }
        } catch (final IOException e) {
            e.printStackTrace();
            ce = null;
        }
        return ce;
    }
----
Where only loadEntry() can throw an IOException.

I get the following warning on the statement 'ce = null;':

Redundant assignment: The variable ce can only be null at this location	

However, without this assignment statement I get an error saying that 'ce' may not have been initialized.

Yes, the warning is correct, and yes, the error is only there because the Java Language Specification requires it, and yes, I can suppress the warning. Nevertheless, I think it is better not to emit this warning in the first place.


Reproducible: Always

Comment 1 Stephan Herrmann

2011-02-26 09:04:16 EST

I can reproduce in HEAD using the following self-contained version of
the test case:

import java.io.File;
import java.io.IOException;

public class Bug338303 {
   Object test(Object in, final File f) {
        Object local;
        try {
            local = in;
            if (local == null)
				local = loadEntry(f, false);
        } catch (final IOException e) {
            e.printStackTrace();
            local = null;
        }
        return local;
    }

    private Object loadEntry(File f, boolean b)  throws IOException {
        throw new IOException();
    }
}

We'll look into this. Thanks for the report.

Comment 2 Stephan Herrmann

2011-02-27 14:23:56 EST

Created attachment 189900 [details]
test & proposed fix

I was pleased to see how well localized this can be fixed: with this
patch we simply refuse to report an assignment to a local as redundant
if the lhs has the bit FirstAssignmentToLocal set.
I believe that's exactly what we need to express here.

Compiler regression tests are currently running.

Comment 3 Stephan Herrmann

2011-02-27 16:46:01 EST

Released for 3.7M6

Comment 4 Ayushman Jain

2011-03-07 09:01:28 EST

Verified for 3.7M6 using build I20110301-1357