Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 367154

Summary:

[compiler][null] Problem in propagating null defaults.

Product:

[Eclipse Project] JDT

Reporter:

Srikanth Sankaran <srikanth_sankaran>

Component:

Core

Assignee:

Stephan Herrmann <stephan.herrmann>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

amj87.iitr

Version:

3.8

Target Milestone:

3.8 M5

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
test & fix	none

Description Srikanth Sankaran

2011-12-20 03:37:25 EST

This is a follow up to bug 365836.

In the following program, I would expect to see an error, but don't.

import org.eclipse.jdt.annotation.NonNullByDefault;
import org.eclipse.jdt.annotation.Nullable;

@SuppressWarnings("unused")
public class X {
     
    public void foo(@Nullable String [] args) {
    	@NonNullByDefault
        class local {
            class Deeply {
                Object zoo() {
                    return null;  // No error here ??
                }
            }
        };
    }
}

Comment 1 Ayushman Jain

2011-12-20 04:41:06 EST

Is this case already captured in a bug?

@NonNullByDefault
public class ShowNPE2 {	 
	 public Object foo(Object o1, final boolean b) {
		 o1 = null;   // MISSING NPE warning
		System.out.println(o1.toString());   
		return null;  // Correct warning
		
	}
}

Comment 2 Srikanth Sankaran

2011-12-20 04:51:53 EST

(In reply to comment #1)
> Is this case already captured in a bug?

I don't think so. Stephan spawn another bug as needed. TIA.

Comment 3 Stephan Herrmann

2011-12-20 10:38:37 EST

Created attachment 208628 [details]
test & fix

(In reply to comment #0)
> This is a follow up to bug 365836.
> 
> In the following program, I would expect to see an error, but don't.

Thanks. When fixing bug 365836 I wasn't aware that types nested in local
types are also treated as local types. This implies that enclosingType
and enclosingMethod cannot easily be used to determine lexical scoping.

Obviously, the better strategy is to use scopes for this traversal.
The attached fix does this.
The tiny downside of this approach is that expressions like
scope.referenceContext.binding can yield nulls in various situations,
which all have to be checked.

Test's are currently running.

Comment 4 Stephan Herrmann

2011-12-20 10:53:49 EST

(In reply to comment #2)
> (In reply to comment #1)
> > Is this case already captured in a bug?
> 
> I don't think so. Stephan spawn another bug as needed. TIA.


See bug 367203.

Comment 5 Stephan Herrmann

2011-12-20 12:27:42 EST

(In reply to comment #3)
> Test's are currently running.

Aggressive version of all JDT/Core tests (ie., with null analysis
enabled by default) essentially pass 
(except for obvious deviation like in BatchCompilerTest).

Released for 3.8 M5 via commit 191f90d8b8e3d032d6a88890167c13d9311990d0

Comment 6 Srikanth Sankaran

2012-01-23 04:22:32 EST

Verified for 3.8 M5 using build id: I20120122-2000