Bug 165917 - Error range for IProblem.IncompatibleReturnType should be predictable
Summary: Error range for IProblem.IncompatibleReturnType should be predictable
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 M4   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 165913
  Show dependency tree
 
Reported: 2006-11-27 09:21 EST by Markus Keller CLA
Modified: 2006-12-12 12:08 EST (History)
2 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 Markus Keller CLA 2006-11-27 09:21:37 EST 
HEAD

The fix for bug 160520 has moved the error range for IProblem.IncompatibleReturnType from the method name and parameter list to the return type. This has caused failing UI tests, see bug 165913.

Unfortunately, I still get the old-style error range for TypeMismatchQuickFixTests.testMismatchingReturnTypeOnGeneric2():

package test1;
public class Base {
    public Number getVal() {
        return null;
    }
}
package test1;
public class E<T> extends Base {
    public T getVal() {
        return null;
    }
}

Could you please select the full return type for all cases of IProblem.IncompatibleReturnType?
Comment 1 Markus Keller CLA 2006-11-27 10:56:19 EST 
(In reply to comment #0)
> Unfortunately, I still get the old-style error range for

Oops, I guess I messed something up here. Im not getting the old-style error
range, but a range that does not include type arguments. E.g. here, the source
range only covers "E", not "E<T>":

public class E<T> extends Base {
    public E<T> getVal() {
        ...
Comment 2 Olivier Thomann CLA 2006-11-27 13:35:37 EST 
In fact we have other errors on parameterized type reference where the type arguments are not part of the problem's range.
So I can fix this one, but we might want to fix all of them.
Comment 3 Philipe Mulet CLA 2006-11-27 17:55:17 EST 
In this very case, selecting the entire parameterized type makes sense. I'd like to see the other ones you are referring to Olivier. It depends where the blame is:

e.g. when complaining about "Object<String>" to be invalid since Object is not generic, then I would only expect "Object" to be selected.
Comment 4 Philipe Mulet CLA 2006-11-27 17:56:04 EST 
To be pragmatic, I would address this one issue, and investigate others in subsequent bugs (if proven to be an issue).
Comment 5 Olivier Thomann CLA 2006-11-27 22:52:16 EST 
Added bug 166004 and bug 166005 to give specific test cases for comment 2.
Comment 6 Olivier Thomann CLA 2006-11-27 22:54:34 EST 
Released for 3.3M4.
Updated existing regression tests:
org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest#test0059/test0384/test0385
org.eclipse.jdt.core.tests.compiler.regression.MethodVerifyTest#test081
Comment 7 David Audel CLA 2006-12-12 12:08:19 EST 
Verified for 3.3M4 with I20061212-0010.