Bugzilla – Full Text Bug Listing
| Summary: | [compiler][null] extraneous error in case of a labeled while(true) statement | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Maxime Daniel <maxime_daniel> | ||||||
| Component: | Core | Assignee: | Maxime Daniel <maxime_daniel> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | markus.kell.r | ||||||
| Version: | 3.3 | ||||||||
| Target Milestone: | 3.3 M7 | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
The problem comes from the fact that we do not mix late null information into the break information of LabelFlowContext (and potentially others). The intervening contexts should bufferize the null implications of recordBreakFrom as they do for other null-related information. This is not a trivial change since it implies storing the flow information and the target for each break, and changing the logic used to climb up the chain of enclosing contexts.
Note that the second test case should be:
void foo(boolean b) {
Object o = null;
done: while (true) {
if (b) {
break done;
}
o = new Object();
}
if (o == null) { // Redundant null check: The variable o can only be
null at this location
}
}
(To be more rigorous, we should even replace the test upon b by a test upon something that has a chance to change.)
Not in 3.3 timeframe. Reopening for moderate priority attempt in 3.3 timeframe. *** Bug 178227 has been marked as a duplicate of this bug. *** Created attachment 61971 [details]
Tentative fix + test cases
I believe the approach of the patch is sound. Kent, could you pls have a look? Created attachment 62484 [details]
Better fix + test cases
Having a look with Philippe, we agreed that the approach was too complex (more over, it broke a test). This patch is much simpler and easier to understand. It also properly passes all existing tests, and remains on the safe side in that it only changes null related information - eliminating any risk to change the more general flow analysis.
Kent, Philippe, pls have a look and let me know what you think.
fine with me Released for 3.3 M7. Verified for 3.3M7 using I20070427-0010 |
I20070228-0930 Upon the following test case, JDT complains while it should not: public class X { void foo(int i) { Object o = null; done: while (true) { switch (i) { case 0: o = new Object(); break; case 1: break done; } } if (o == null) { // Redundant null check: The variable o can only be null at this location } } void foo(boolean b) { Object o = null; done: while (true) { if (b) { break done; } } if (o == null) { // Redundant null check: The variable o can only be null at this location } } } Released (inactive) test cases NullReferenceTest#460 and 461.