Community
Participate
Working Groups
I20110124-1800 Wrong compiler problem "The value of the local variable xxx is not used" if there's a real compile error later: public class Test { void foo(String m) { // wrong "The value of the local variable message is not used": final String message= m; new Runnable() { public void run() { if ("x".equals(message)) { bug(); // undefined method } } }.run(); } }
I'll take a look.
Released disabled junit test via org.eclipse.jdt.core.tests.compiler.regression.ProgrammingProblemsTest._test0058() Turns out the local variable's use is recorded in code generation. Given we don't generate code for the class with the error, the only use of the local is missed resulting in the warning. I'll see how best to handle this.
Created attachment 188976 [details] Proposed patch
Passes all tests, Ayush please review, TIA. See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=95909
Released in HEAD for 3.7 M6
Patch looks good. Although initially I thought that its too harsh to stop reporting variable unused problem when there's any error in the code, I observed that this is being done anyways by the use of ignoreFurtherInvestigation flag which gets set on the method whenever an error is encountered. And because of this flag being set, no analysis takes place for the method in question. So this bug can only occur in the kind of case as reported i.e. an inner method inside an anonymous class has the error, and gets marked with ignoreFurtherInvestigation, but the outer method does not. So in the outer method's analysis, we dont analyse the inner method, and hence dont encounter the usage of 'message' inside the inner method. So its better to not report unused warnings when such a scenario occurs.
Verified for 3.7M6 using build I20110301-1537
OK, given that it is not possible to fix all cases (see bug 343621) with this fix, we should revert it for 3.7.
The right way to fix it would be to check if the current method contains errors. We don't have an easy way to check this right now. The "usage" of the message is only checked really late in the code generation when outer locals are injected into the code generation of the anonymous class. Since there is a problem with that code, the outer local variable emulation is never done.
(In reply to comment #9) > The right way to fix it would be to check if the current method contains > errors. We don't have an easy way to check this right now. The "usage" of the > message is only checked really late in the code generation when outer locals > are injected into the code generation of the anonymous class. > Since there is a problem with that code, the outer local variable emulation is > never done. A think the cleanest way of fixing this would be to move usage analysis from generateCode to analyseCode, see bug 328830. The latter bug, however, should better be addressed in some M1 or M2 at the latest, IMHO.
(In reply to comment #10) > (In reply to comment #9) > > The right way to fix it would be to check if the current method contains > > errors. We don't have an easy way to check this right now. The "usage" of the > > message is only checked really late in the code generation when outer locals > > are injected into the code generation of the anonymous class. > > Since there is a problem with that code, the outer local variable emulation is > > never done. > > A think the cleanest way of fixing this would be to move usage analysis from > generateCode to analyseCode, see bug 328830. The latter bug, however, should > better be addressed in some M1 or M2 at the latest, IMHO. Concur with Stephan. Moving it out of 3.8 and tagging as plan candidate for 3.9. Thanks Stephan.
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. If you have further information on the current state of the bug, please add it. 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.
After bug 328830 turned out to be a dead end we are left without a solution strategy. Given that this is about secondary errors in the presence of real high prio errors, I don't see sufficient motivation for creating yet another solution strategy.
Verified for Eclipse Version: 2019-12 (4.14) M1 with Build id: I20191008-1800
