Bug 129371 - [compiler][null] False positives from null reference analyzer with break
Summary: [compiler][null] False positives from null reference analyzer with break
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: 3.2 M6   Edit
Assignee: Maxime Daniel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-24 12:08 EST by Eugene Kuleshov CLA
Modified: 2006-04-13 10:51 EDT (History)
0 users

See Also:


Attachments
Suggested patch + test cases (7.29 KB, patch)
2006-03-22 09:02 EST, 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 Eugene Kuleshov CLA 2006-02-24 12:08:35 EST
Eclipse is reporting "The variable s may be null" at s.lenght() in the following code.
It seems has something todo with "break"...

  private void aa() {
    for(int i = 0; i < 10; i++) {
      String s = get();
      if(s != null) {
        for(int j = 0; j < 1; j++) {
          break;
        }
        s.length();
      }
    }
  }

  private String get() {
    return null;
  }
Comment 1 Maxime Daniel CLA 2006-03-22 08:43:34 EST
This is related to the cancellation of null related information at the very beginning of the loop. As a side effect, the inits on break lack knowledge about the upstream null info (here, s is protected non null before entering the loop). The proposed remedy is to reinject the upstream null info when needed (as we do for the null info resulting from the loop action).
Added test cases NullReferenceTest #732 to 735 to illustrate the case in all loops.
Comment 2 Maxime Daniel CLA 2006-03-22 09:02:08 EST
Created attachment 36737 [details]
Suggested patch + test cases
Comment 3 Maxime Daniel CLA 2006-03-22 09:45:58 EST
Fixed and released in HEAD.
Verification can use the initial test case and other loop combinations.
Comment 4 David Audel CLA 2006-04-13 10:51:55 EDT
Target Milestone must be 3.2M6 and not 3.2RC1. I correct it.

Verified for 3.2 M6 using build 3.2M6