Bug 48399 - [compiler] Enhance unreachable code detection
Summary: [compiler] Enhance unreachable code detection
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1.2   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 3.5 M4   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 51952 110544 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-12-10 05:03 EST by Gunnar Wagenknecht CLA
Modified: 2009-05-24 08:36 EDT (History)
4 users (show)

See Also:

Attachments
Proposed patch (64.34 KB, patch)
2008-11-21 05:21 EST, Philipe Mulet CLA 		no flags Details | Diff
Better patch (70.97 KB, patch)
2008-11-21 07:20 EST, Philipe Mulet CLA 		no flags Details | Diff
Final patch (204.88 KB, patch)
2008-11-24 08:12 EST, Philipe Mulet CLA 		no flags Details | Diff
Addition to previous patch (7.46 KB, patch)
2008-11-25 07:31 EST, Philipe Mulet CLA 		no flags Details | Diff
Show Obsolete (2) View All 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 Gunnar Wagenknecht CLA 2003-12-10 05:03:58 EST 
I'm not sure if this use case is already included in the 3.0 enhancements but 
it is not recognized in 2.1.2. Thus, I'm adding it to bugzilla.


public void myMethod()
{
    boolean performOK = false;

    [some opertations that never modify performOk (no write access to 
performOk)]

    if(performOK && .....)
    {
        // this code will be unreachable 
        // jdt compile can recognize this but doesn't in 2.1.2
    }
}
Comment 1 Philipe Mulet CLA 2003-12-10 05:23:15 EST 
As per JLS, this code cannot be flagged as unreachable. But an extra warning 
for such a scenario could be useful indeed. Though it requires quite a bit of 
work in order to get there.

Will consider later.
Comment 2 Philipe Mulet CLA 2005-08-30 16:04:42 EDT 
*** Bug 51952 has been marked as a duplicate of this bug. ***
Comment 3 Philipe Mulet CLA 2007-04-02 07:20:51 EDT 
*** Bug 110544 has been marked as a duplicate of this bug. ***
Comment 4 Philipe Mulet CLA 2007-04-02 07:21:09 EDT 
reopening
Comment 5 Philipe Mulet CLA 2008-11-21 05:19:35 EST 
Re: comment 1
It will now work if the variable is made a constant.

public void myMethod(){
    final boolean performOK = false;
Comment 6 Philipe Mulet CLA 2008-11-21 05:21:02 EST 
Created attachment 118447 [details]
Proposed patch

(hacking at Stuttgart airport on way back from ESE)
Comment 7 Philipe Mulet CLA 2008-11-21 05:26:24 EST 
Added FlowAnalysisTest#test052-057
Comment 8 Philipe Mulet CLA 2008-11-21 07:20:50 EST 
Created attachment 118458 [details]
Better patch
Comment 9 Philipe Mulet CLA 2008-11-24 08:12:57 EST 
Created attachment 118586 [details]
Final patch

Enabled the warning in test suites
Comment 10 Philipe Mulet CLA 2008-11-24 08:18:56 EST 
Released for 3.5M4.
Fixed
Comment 11 Philipe Mulet CLA 2008-11-25 07:31:13 EST 
Created attachment 118651 [details]
Addition to previous patch

Takes care of scenario like:

int i = false && b ? 0 : 1;

which is now reporting 2 instances of dead code (instead of one before extra patch).

----------
1. WARNING in X.java (at line 3)
	int i = false && b ? 0 : 1;
	                 ^
Dead code
----------
2. WARNING in X.java (at line 3)
	int i = false && b ? 0 : 1;
	                     ^
Dead code
----------
Comment 12 Philipe Mulet CLA 2008-11-25 07:32:29 EST 
Also added FlowAnalysisTest#test058-059, and enabled the diagnostic on entire compiler test suites.
Comment 13 Jerome Lanneluc CLA 2008-12-09 04:42:28 EST 
Verified for 3.5M4 using I20081209-0100
Comment 14 Stephan Herrmann CLA 2009-05-24 08:36:58 EDT 
Is it by intention that this diagnostic is configurable
via preferences/command line arg, but not suppressable
using a @SuppressWarnings("deadCode") annotation?

This looks inconsistent to me.

Also the discussion in bug 256463 doesn't mention
suppressing using an annotation. Just an oversight?