Summary: | [1.5][compiler] Spurious 'type parameter T is hiding the type T' warning for static nested classes | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | David Mandelin <mandelin> |
Component: | Core | Assignee: | David Audel <david_audel> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | minor | ||
Priority: | P3 | CC: | martinae |
Version: | 3.1 | ||
Target Milestone: | 3.1.1 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
David Mandelin
2005-06-06 11:32:56 EDT
I agree we shouldn't complain about hiding here, as outer T isn't accessible in context. Added GenericTypeTest#test774. Tuned hiding check on TypeParameter, also ensured check is performed for generic method type parameters. Fixed Verified in 3.2 M1 with build I20050808-2000. Verified using M20050923-1430 for 3.1.1 I have the same warning when implementing List as follows: public class ReadOnlyListProxy<T> extends AbstractProxy<List<T>> implements List<T> { ... public <T> T[] toArray(T[] a) {// The warning comes on this line return getData().toArray(a); } } getData is defined in AbstractProxy<T> as: protected T getData() { return theReference.get(); } All the other methods of List are fine. The signature of the offending method is identical to the one in List. Right, but this one is a case where one definition of T (on method) is hiding the one from the enclosing type. So you cannot use the enclosing type parameter T within the method. It is the intent of this warning to report such a case. What do you see being wrong here ? I guess I expect the signature of my implemenation of List<E> to be the same as the interface. In fact any changes I made to it just gave an error that I was not implementing the method. This signature is just what I got when I asked Eclipse to implement the method. Also the method works fine. How could the declaration be changed to remove the warning? Simply rename the type parameter on the method to not collide: public <U> U[] toArray(U[] a) {// The warning comes on this line return getData().toArray(a); } note that interface List<E> defines <T> toArray (observe non conflicting type parameter names). Now you have a point. The tooling shouldn't generate a method signature which exposes this warning (it should perform substitution for you). David/Martin: whose bug is this ? That's probably ours. Please file a new bug request. We have a bug in JDT/Core because we compute a bad signature and a bad completion string in our proposal. But i believe that JDT/Text don't use our completion string. So i suspect a bug on both side. I opened a new CodeAssist bug in JDT/Core for this problem (bug 128169). I close this one because the original problem of this bug is fixed. (In reply to comment #10) > Now you have a point. The tooling shouldn't generate a method signature which > exposes this warning (it should perform substitution for you). Thanks for your help. Now I would like to get disconnected from this bug, but I can's see how. |