Bug 84720 - [1.5][assist] proposal ranking by return value should consider auto(un)boxing
Summary: [1.5][assist] proposal ranking by return value should consider auto(un)boxing
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 3.5 M7   Edit
Assignee: Jay Arthanareeswaran CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 271295 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-02-08 13:03 EST by Tom Hofmann CLA
Modified: 2009-04-28 05:31 EDT (History)
2 users (show)

See Also:

Attachments
Proposed patch (7.18 KB, patch)
2009-04-23 04:12 EDT, Jay Arthanareeswaran CLA 		no flags Details | Diff
Latest patch (7.10 KB, patch)
2009-04-24 05:14 EDT, Jay Arthanareeswaran CLA 		david_audel: iplog+
david_audel: review+
Details | Diff
Show Obsolete (1) View All 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 Tom Hofmann CLA 2005-02-08 13:03:07 EST 
I20050202 (jdt-core from 20050207)

- invoke content assist in the following locations (|)

void method(List list) {
    Integer type= list.| 
    int primitive= list.|
}

expected: proposals are ranked about the same in both locations
actual: for the primitive, the List methods returning an int (indexOf, size,
hashCode) are ranked high. For the Integer, the methods returning void (add...)
are ranked the highest.

I would support ranking autoboxing-proposals a little lower than direct matches,
but autoboxing-proposals should still rank before the big mass (e.g. methods
with a void return type).
Comment 1 Srikanth Sankaran CLA 2009-04-09 02:24:10 EDT 
*** Bug 271295 has been marked as a duplicate of this bug. ***
Comment 2 Srikanth Sankaran CLA 2009-04-09 02:33:12 EDT 
Though the defect title mentions only return value, in many other
contexts also we should consider auto(un)boxing. For one example
see bug #271295
Comment 3 Jay Arthanareeswaran CLA 2009-04-23 04:12:18 EDT 
Created attachment 132897 [details]
Proposed patch

This fix does a compatibility check for the left hand and right hand side type and if found compatible, uses R_EXPECTED_TYPE as the relevance value. Test cases are part of the patch.
Comment 4 David Audel CLA 2009-04-23 11:49:09 EDT 
Comment on attachment 132897 [details]
Proposed patch

Autoboxing is a 1.5 features, so the compatibility check should be done only if compliance is at least 1.5.
Comment 5 Jay Arthanareeswaran CLA 2009-04-24 05:14:35 EDT 
Created attachment 133082 [details]
Latest patch

Instead of calling the LookupEnvironment.computeBoxingType method, modified the fix to use Scope.isBoxingCompatibleWith, which already handles the compiler compatibility checks.
Comment 6 David Audel CLA 2009-04-27 05:36:10 EDT 
Comment on attachment 133082 [details]
Latest patch

This patch is good.
Comment 7 David Audel CLA 2009-04-27 05:37:45 EDT 
Released for 3.5M7.
Comment 8 David Audel CLA 2009-04-28 05:31:46 EDT 
Verified for 3.5M7 using I20090427-1800.

I found a problem in relevance computation while verifying this bug. I entered bug 273991 for this problem.