Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 337903 - [quick fix] for raw type warning, should at least be as good as for unresolved type
Summary: [quick fix] for raw type warning, should at least be as good as for unresolve...
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 3.7 M6   Edit
Assignee: Markus Keller CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-22 16:26 EST by Markus Keller CLA
Modified: 2011-02-22 18:22 EST (History)
0 users

See Also:


Attachments
Fix (6.95 KB, patch)
2011-02-22 18:13 EST, Markus Keller CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2011-02-22 16:26:23 EST
HEAD

The quick fix for a raw type warning should at least be as good as for an unresolved type.

import java.util.*;
public class Try {
    void foo(Stack<List<Integer>> stack) {
        List li= stack.pop();
        Lost lo= stack.pop();
    }
}

For the first type (List), the only quick fix is Infer Generic Type Arguments, and that infers List<?>.

But for the second type (Lost), the first quick fix offers to change the type to List<Integer>, which is all we need.

Bug 318433 should fix Infer Generic Type Arguments, but we should still enable the working quick fix that just fixes that problem. Beware of duplicate quick fixes when the file doesn't contain any compile errors (just warnings)!
Comment 1 Markus Keller CLA 2011-02-22 18:13:53 EST
Created attachment 189562 [details]
Fix
Comment 2 Markus Keller CLA 2011-02-22 18:22:28 EST
> Bug 318433 should fix Infer Generic Type Arguments, but we should still enable
> the working quick fix that just fixes that problem. Beware of duplicate quick
> fixes when the file doesn't contain any compile errors (just warnings)!

Didn't add this smartness for several reasons:

- The "Add type arguments" quick fix only adds type arguments, but the new quick fix "Change type to ***" can also change the base type.

- The "Add type arguments" quick fix also helps in other cases (e.g. unsafe method invocation on a raw variable).

- For perceived UI stability, it's better to accept some redundancy than to hide one of the proposals in case they match.

- It is not easy to find out what the "Add type arguments" quick fix will do, so the duplication is hard to detect.


Fixed in HEAD.