Bug 184298 - [compiler][null] Spurious "Variable can only be null" warning in case of an infinite loop
Summary: [compiler][null] Spurious "Variable can only be null" warning in case of an i...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2.2   Edit
Hardware: PC Linux
: P4 normal (vote)
Target Milestone: 3.4 M2   Edit
Assignee: Maxime Daniel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 198955 212283 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-26 14:22 EDT by Eric Estievenart CLA
Modified: 2007-12-10 05:21 EST (History)
2 users (show)

See Also:
kent_johnson: review+


Attachments
Fix + test cases (4.65 KB, patch)
2007-05-22 08:03 EDT, Maxime Daniel CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Estievenart CLA 2007-04-26 14:22:53 EDT
Build ID: M20070212-1330

Steps To Reproduce:
1. Compile following method in any class
2. Have null reference warning activated
3. you should see a warning on the marked line

Obviously the warning is wrong (if a = { "xx", null }, key is not null).
If you add a test in the for loop as described, the warning disappears.


More information:
  public void test( String[] a )
  {
    String key = null;
// if the following line is replaced by:    
//    for( int i = 0; i < a.length; i++ )
// the warning does not show up.     
    for( int i = 0; ; i++ )
    {
      if( a[ i ] == null )
        break;
      key = a[ i ];
    }
    
    if( key != null )    // <<< WARNING Here "Key can only be null"
    {
      // do something
    }
  }
Comment 1 Maxime Daniel CLA 2007-04-27 00:37:04 EDT
Reproduced with M20070212-1330 and I20070418-1012.
Comment 2 Maxime Daniel CLA 2007-05-02 05:00:45 EDT
Released new tests NullReferenceTest#418, 462 and 743 as inactive (because they are broken), and 419, 463 and 744 as active. The latter tests show that a break to an explicit label does not raise the unexpected warning. This may lead us to consider what we did for explicit labels for bug 176472 and see what may also apply to default break targets.
Comment 3 Maxime Daniel CLA 2007-05-22 08:03:50 EDT
Created attachment 68102 [details]
Fix + test cases

This fix merely amends the initsOnBreak of LoopingContext-s just before doing the same to the initsOnBreak-s of explicit LabelContext-s (for the same LoopingContext). This typically ensures that the inits on a break statement 'see' what happens after them in the loop body, so that a break hit at the Nth iteration, N > 1, gets the result of N - 1 complete iterations plus a partial Nth iteration (whereas we used to only record the part of all iterations that was before the break statement).
Patch currently under test.
Comment 4 Kent Johnson CLA 2007-05-22 10:59:23 EDT
looks straight forward
Comment 5 Maxime Daniel CLA 2007-09-07 12:42:00 EDT
Released for 3.4 M2.
Comment 6 Maxime Daniel CLA 2007-09-10 02:31:46 EDT
*** Bug 198955 has been marked as a duplicate of this bug. ***
Comment 7 Jerome Lanneluc CLA 2007-09-18 07:14:50 EDT
Verified for 3.4M2 using I20070917-1800
Comment 8 Maxime Daniel CLA 2007-12-10 05:21:08 EST
*** Bug 212283 has been marked as a duplicate of this bug. ***