Summary: | [1.5] [compiler] Eclipse compiler fails to report type parameter bounds errors when generic instance is a type argument | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Sasha Kogan <sashak> | ||||||
Component: | Core | Assignee: | Kent Johnson <kent_johnson> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | david_audel, jarthana, philippe_mulet | ||||||
Version: | 3.2 | ||||||||
Target Milestone: | 3.5 M7 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows XP | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Sasha Kogan
2006-10-05 05:42:14 EDT
Reproduced... strange. Actually our boundcheck is not strict enough for type arguments at depth > 1. I think this is something which has changed under us, and we should realign. We encountered this bug with : public class GenericClass<T extends Number> { } public class GenericClassTwo<T> { } public class EclipseCompilerTest<T> extends GenericClassTwo<GenericClass<T>> { } with 1.6 javac: EclispeCompilerTest.java:2: type parameter T is not within its bound public class EclispeCompilerTest<T> extends GenericClassTwo<GenericClass<T>> { No error or warning with Eclipse 3.2.1 or 3.2.2 The following might be a variant of the same issue (javac reports an error on line marked 1): class X<T> { static class XX<U> extends X<U> { class XXX<V extends I<U>> extends XY<V> { // 1 } } class XY<W extends I<T>> { } } interface I<T> { } Created attachment 130282 [details]
Proposed patch and testcase
Philippe - let me know if this patch works for you & I'll release it
It passes all of our existing tests
Created attachment 130461 [details]
Proposed patch and testcase
This patch remembers each TypeRef that we delayed the boundsCheck & does it after the hierarchy is attached
Fix and test released for 3.5M7 Forgot to mark as fixed Kent, The compiler doesn't report any problem on the code given in the comment #4. Should we treat this as a separate test case? What's your opinion on this one? Jay b55 of javac 7.0 also doesn't report an error on the case in comment #4 I believe we are correct for this case. Verified for 3.5M7 using I20090428-0100 |