Bug 45357 - Compiler-Bug: "The local variable oResult may not have been initialized".txt
Summary: Compiler-Bug: "The local variable oResult may not have been initialized".txt
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 2.1.3   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 45365 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-10-22 06:28 EDT by markusle CLA
Modified: 2004-04-07 10:04 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description markusle CLA 2003-10-22 06:28:10 EDT
From the newsgroup:

Hello,

I believe I found a Java compiler bug in Eclipse M4 (my fifth or so ;-);
see the method "badUninitializedVariableErrorMessage()" in the example
below.

/**
 * class CompileError
 */
public class CompileError {
private static final class MethodProvider {
// If you remove the 'throws Exception': The error Message disapears
    public Object openAppletJarOf(Object o) throws Exception {
        return null;
    }
}
/**
* This method compiles with a Compiler Error:
* "The local variable oResult may not have been initialized"
* Question: Why?
*/
public static Object badUninitializedVariableErrorMessage(//
) throws Exception {
    final MethodProvider oMethodProvider = new MethodProvider();
    final boolean bFlag1 = !true, bFlag2 = !true;
    // If you uncomment the next if-else: The error Message disapears
    if (!bFlag1) {
        final Object o2 = null;
    } else {
        final Object o2 = oMethodProvider.openAppletJarOf(null);
    }
    final Object oResult, o1 = null;
    if (o1 != null) {
        oResult = null;
        oMethodProvider.openAppletJarOf(null);
    } else {
        // If you uncomment the next line: The error Message disapears
        final Object o4 = oMethodProvider.openAppletJarOf(null);
        oResult = null;
    }
    return oResult;
}
}


Kind Regards 

Mle
Comment 1 Philipe Mulet CLA 2003-10-22 07:53:36 EDT
I confirm this is a bug. Will investigate.
Comment 2 markusle CLA 2003-10-22 08:04:27 EDT
Hipp Hipp, Hurra! If I report my 10. Compiler bug 
I want win a golden banana: Is that possible? :-}
Comment 3 Philipe Mulet CLA 2003-10-22 08:59:14 EDT
*** Bug 45365 has been marked as a duplicate of this bug. ***
Comment 4 Philipe Mulet CLA 2003-10-22 09:01:33 EDT
Sure ! <g> btw, I couldn't find your other 4 (or so) reported bugs against the 
compiler...
Comment 5 markusle CLA 2003-10-22 09:32:47 EDT
When I found bug 10 -- in one or two days ;-)  -- I collect
my other bug reports, most of them are reported by other people:
I first ask in the newsgroup "Is it a bug", and most of the time 
a kind reader reports the bug for me.
Comment 6 Philipe Mulet CLA 2003-10-22 10:58:13 EDT
Problem was due to a missing copy of a flow info during exception analysis. 
Thus a side-effect got performed on original object, affecting further 
diagnosis.

Fixed. Regression test added InitializationTest#test169
Comment 7 markusle CLA 2003-10-23 01:50:00 EDT
/* Bug 6: I don't open a new bug report for this kind of bug, 
 * because it is possible that you don't like my humor:
 * I don't want to waste a bug report for a (possibly) bad joke,
 * but a comment on an exisitng bug report ... .
 * If this kind of bug count, then the banana is near. 
 */
/**
 * This method compiles with a Compiler Warning:
 * "The local variable bStopRecursion is never read"
 * Question: Why?
 * Possible fix: Change Warning to:
 *    "The local variable bStopRecursion is superfluous"
 */
public static void usedVariableReportedAsUnread(final boolean bStop) {
	final boolean bStopRecursion;
	if (bStop) {
		// ok
	} else {
		usedVariableReportedAsUnread(bStopRecursion = true);
	}
}
Btw I can explain why this construct is useful .... 
Comment 8 Philipe Mulet CLA 2003-10-23 08:28:21 EDT
This warning is telling you that the variable is never read, thus could be 
optimized out. Note that for debugging purpose, one may choose to preserve 
these, then you should simply turn the warning off.
Comment 9 Philipe Mulet CLA 2003-10-23 08:29:26 EDT
You should always enter a new bug for a new issue. We can close it if wrong, 
don't worry.
Comment 10 markusle CLA 2003-10-23 08:42:56 EDT
Continued from:
   https://bugs.eclipse.org/bugs/show_bug.cgi?id=45357
>This warning is telling you that the variable is never read, thus could be 
>optimized out. 
I think it is not clear that this variable is never read, it depends on the
interpretation (it is clear that it can become optimzed away but that is 
another theme):
 * int a,b,c,d;
 * How to interprete: a=b=c=d;
 * Interprete as function call:
 * Interpretatin 1: =a(=(b,=(c,d)))                 // a,b,c,d never read
 * Interprete as decomposable expression:
 * Interpretatin 2: t1=(c=d); t2=(b=t1); t3=(a=t2)  // a,b,c,d never read
 * Interprete as decomposable expression with reduced temp variable set:
 * Interpretatin 3: c=(c=d); b=(b=c); a=(a=b)       // b,c,d read; a not
 * How to interprete: a=d;
 * Interpretation A: As atomic expression a=b; // a never read
 * Interpretation B: As minmal assignmend chain a=b; --> a= (a=b) // a read
 * My prefered interpretation of a=b; is the Interpretation B.
>Note that for debugging purpose, one may choose to preserve these, 
>then you should simply turn the warning off.
The is a bad workaround, because I always want a warning for really unused 
variables but my 'bStopRecursion' is used (in my interpretation B).

Sorry, but you are my new victim for useless discussion (the last was Oliver
Thomann a few month ago).

Kind Regards

Comment 11 Philipe Mulet CLA 2003-10-23 09:06:09 EDT
No problem. My point is more at the generated code level. There are 2 
instructions for reading or writing a local variable. When stating 'a = b', 
variable b is read, and variable a is written. 

The warning is only indicating variable which are not read, not variables which 
aren't used at all (we originally implemented this, but user feedback conducted 
us to rather signal unread variables).
Comment 12 markusle CLA 2003-10-23 09:35:03 EDT
 * I think that is not my point:
 * Assume there is a real piece of Java Code
 *    int x;
 *    Math.abs(x=1);
 * Your prefered way to byte code interpretes x as unread:
 *    final int x;
 *    // looks like raw SSA: static single assignment
 *    final int t = x=1; // t is a Compiler internal variable
 *    Math.abs(t); // read t not x
 * My prefered way to byte code reads x (instead of t)
 *    final int x;
 *    x=1; // Still real SSA but :
 *    Math.abs(x); // x is read
 * I stop discussion, if get some food (perhaps a very small tangerine?)
Comment 13 David Audel CLA 2003-11-20 07:25:55 EST
Verified.
Comment 14 Philipe Mulet CLA 2003-11-25 07:45:17 EST
Backported to 2.1.x stream
Comment 15 David Audel CLA 2004-03-01 12:47:05 EST
Verified for 2.1.3 (M20040225)
Comment 16 okano CLA 2004-04-06 21:39:49 EDT
/* this warning is right? */
final int a;
System.out.println(a=1);
// compiler sais cannot read 'a'
Comment 17 Philipe Mulet CLA 2004-04-07 10:04:09 EDT
okano: please file separate bug report for your issue. Don't append to close 
ones.