Bug 174447 - [1.5][compiler] Infered type in case of recursive bound
Summary: [1.5][compiler] Infered type in case of recursive bound
Status: RESOLVED DUPLICATE of bug 121369
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-16 10:09 EST by Rémi Forax CLA
Modified: 2008-09-03 05:02 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rémi Forax CLA 2007-02-16 10:09:51 EST
Build ID: I20070209-1006

Steps To Reproduce:
1. compile the following code

public class EclipseBug1 {
    public static <E extends Enum<E>> void f() {
    }
    
    public static void main(String[] args) {
      f();
    }
}

More information:
The error message is weird:
"Bound mismatch: The generic method f() of type EclipseBug1 is not applicable for the arguments (). The inferred type Enum<Enum<E>> is not a valid substitute for the bounded parameter <E extends Enum<E>>"

The inferred type can't be Enum<Enum<E>> because we don't
provide any E. Futhermore javac infers java.lang.Object
and i think it is closer to that the JLS says.

Rémi
Comment 1 Maxime Daniel CLA 2007-02-23 05:26:49 EST
javac (1.5, 6, 7) says:
EclipseBug1.java:6: incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) E
found   : <E>void
required: void
    f();
     ^
1 error

While I agree that the bound we publish looks quite mysterious, I believe that the second part of our message is better (since it gives more information about the type parameter expected by f).

Except if we can find cases where greater damages are caused by the said odd bound (aka if we find instances in which the error message is outrightly misleading, or even the code fails whereas it should not or the other way round) or Philippe says otherwise, I would suggest a WONTFIX here.

Philippe, what do you think?
Comment 2 Rémi Forax CLA 2007-02-23 13:26:53 EST
(In reply to comment #1)
> javac (1.5, 6, 7) says:
> EclipseBug1.java:6: incompatible types; inferred type argument(s)
> java.lang.Object do not conform to bounds of type variable(s) E
> found   : <E>void
> required: void
>     f();
>      ^
> 1 error
> 
> While I agree that the bound we publish looks quite mysterious, I believe that
> the second part of our message is better (since it gives more information about
> the type parameter expected by f).

i agree that your message is more explicit but
your bound is not correct.
perhaps the problem is not the error message
but how the argument type is processed.
thus i believe the second part of the message should be :

"The inferred type Object is not a valid substitute
for the bounded parameter <E extends Enum<E>>"

> 
> Except if we can find cases where greater damages are caused by the said odd
> bound (aka if we find instances in which the error message is outrightly
> misleading, or even the code fails whereas it should not or the other way
> round) 

the way an implicit argument of a parameter type is infered is
specified by the JLS, and in that example the inference fails
so the infered type should be Object and not Enum<Enum<E>>.

> or Philippe says otherwise, I would suggest a WONTFIX here.
> 
> Philippe, what do you think?
> 
Comment 3 Maxime Daniel CLA 2007-02-26 03:49:09 EST
I believe that the issue comes from ParameterizedGenericMethodBinding (round line 421), that fails to recognize self-referencing types early enough.
Moving to Philippe for comments.
Comment 4 Philipe Mulet CLA 2007-02-27 06:18:19 EST
Will look, indeed it feels that the message is not appropriate; though the code is correctly rejected.
Comment 5 Philipe Mulet CLA 2008-04-21 07:29:06 EDT
Also see bug 121369.
I do not think it should reflect Object in the end, according to JLS15.12.2.8. It would yield Enum<E> for E, which still contains reference to unbound E.
This is part of a larger problem, will wait until spec is being clarified.
Comment 6 Philipe Mulet CLA 2008-04-21 07:31:15 EDT

*** This bug has been marked as a duplicate of bug 121369 ***
Comment 7 Philipe Mulet CLA 2008-09-03 05:02:18 EDT
Added GenericTypeTest#test1380