Description Tom Hofmann 2005-09-23 04:00:47 EDT

We currently do some magic when completing generic Java types. According to
Philippe (via Dani), this is something that jdt-core could do more efficiently
and that you may want to take over. This PR exists to track this issue.

We currently do the following if 'Java>Editor>Code Assist>Fill Parameters' is
enabled:

- if there is no expected type, the type parameter names are entered and set up
with linked mode to be filled in

    Ex: complete
       ArrayLi|
    to
       ArrayList<E> // E is selected

- if there is an expected type, we try to compute the type arguments and insert
them. Type arguments that cannot be unambiguously determined are set up with
linked mode.

    Ex: complete
       Map<String, ? extends Number> map= new HashM|
    to
       Map<String, ? extends Number> map= new HashMap<String, Number>
       // String is unambiguous, but Number gets selected as the user may change

- if the inserted type is not a subtype of the expected type, we assume that the
user wants an inner type and do not insert any arguments at all.

    Ex: complete
       Map.Entry<?,?> entry= new HashMa|
    to
       Map.Entry<?,?> entry= new HashMap
       // no arguments, as HashMap is not a subtype of Entry



From this, the following information needs to be available from a TYPE_REF
completion proposal:
- whether the proposal is a subtype of the expected type
- the type parameter names (in case there are no argument guesses)
- any proposed type arguments (corresponding to the expected type)
- the type arguments should be ITypeBindings so we know whether a proposal is
ambiguous (wildcard or type variable) or not.
- the above information needs to be computed lazily, so we can query for it when
the user applies a TYPE_REF proposal.