Bugzilla – Full Text Bug Listing
| Summary: | [compiler][null] inconsistent error reporting. | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Srikanth Sankaran <srikanth_sankaran> |
| Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | amj87.iitr |
| Version: | 3.8 | ||
| Target Milestone: | 3.8 M5 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
Fixing was straight-forward: ReturnStatement reported the nullity mismatch directly to the ProblemReporter instead via the FlowContext, which is required to consider the enclosing loop. By calling flowContext.recordNullityMismatch(..) reporting is deferred until we have the necessary information from the loop. I double checked that this was the last location taking this "shortcut", now all reports properly go via the FlowContext. Released for 3.8 M5 via commit 8e77108c42837d2f8e34e3f8fd4f8eea8e97b2f7 Verified for 3.8 M5 using build id: I20120122-2000 |
3.8 M4 candidates. In the following program both the assignment and return statement are violating the null contracts in exactly the same way, but the diagnostics are different. One is a warning and the other an error. This is inconsistent: import org.eclipse.jdt.annotation.NonNull; import org.eclipse.jdt.annotation.NonNullByDefault; import org.eclipse.jdt.annotation.Nullable; public class X { @NonNull public Object foo(Object x, int y) { @NonNull Object local; while (true) { if (y == 4) { local = x; // error return x; // only a warning. } x = null; } } }