Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 438467 - [compiler][null] Better error position for "The method _ cannot implement the corresponding method _ due to incompatible nullness constraints"
Summary: [compiler][null] Better error position for "The method _ cannot implement the...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.4   Edit
Hardware: PC Linux
: P3 trivial (vote)
Target Milestone: 4.5 M1   Edit
Assignee: Stephan Herrmann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 438397 438469 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-06-28 18:06 EDT by Michael Vorburger CLA
Modified: 2014-08-05 08:01 EDT (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Vorburger CLA 2014-06-28 18:06:47 EDT 
The error marker:
 
"The method @Nullable (someMethod) from (someClass) cannot implement the corresponding method from (someInterface) due to incompatible nullness constraints"

has the line location of (someClass). In an ideal world, it would obviously be (someMethod) instead, to allow one to correct the problem more easily by double clicking and jumping to the correct line.

This is certainly a minor problem in the larger scheme of things of null analysis, but I thought I'd let you know anyways.
Comment 1 Stephan Herrmann CLA 2014-07-22 04:40:47 EDT 
This is blocking the use of @SuppressWarnings("null") in bug 438469.
Comment 2 Stephan Herrmann CLA 2014-07-22 10:31:24 EDT 
The sub-optimal error location corresponds to raising a sub-optimal error: instead for reporting "cannot implement ... due to incompatible ..." we should explicitly say: "The return type is incompatible with ...".

Technically this means: whenever we do have the AST of the method to complain against, use problemReporter().illegalReturnRedefinition() instead of problemReporter().cannotImplementIncompatibleNullness().
The latter is a fallback for a situation of which I'm not sure whether it can actually occur.

To match the same situation for parameter incompatibilities which do not fit the old messages for SE5 null annotations, I added IProblem.IllegalParameterNullityRedefinition.

I had to rephrase one existing error message to make it suitable for type annotations, too, which required update to a number of existing tests ...

Messages are now:
914 = The return type is incompatible with ''{1}'' returned from {0} (mismatching null constraints)

972 = Illegal redefinition of parameter {0}, inherited method from {1} declares this parameter as ''{2}'' (mismatching null constraints)
Comment 4 Stephan Herrmann CLA 2014-07-22 15:05:15 EDT 
*** Bug 438397 has been marked as a duplicate of this bug. ***
Comment 5 Stephan Herrmann CLA 2014-07-31 04:53:40 EDT 
*** Bug 438469 has been marked as a duplicate of this bug. ***
Comment 6 Manoj N Palat CLA 2014-08-05 08:01:26 EDT 
Verified for Eclipse Mars 4.5 M1 Build id: I20140804-2000