Community
Participate
Working Groups
Build 3.3M6 Hovering on top of #toArray(...) message sending in following code reveals poor handling of anonymous types: "<141> 141[] X.toArray(141 t)" public class X { static <T> T[] toArray(T t) { return null; } public static void main(String[] args) { System.out.println(toArray(new Object(){})); } }
Created attachment 62776 [details] Offending hover
- Is this fixable on the JDT/UI side? We get the resolved label that contains these number as types - Is this corner case?
I think it should rather be addressed by information in the binding key itself (i.e. instead of a number, it should remember the supertype S, so as to be able to render: new S(){}).
JDT.Core should probably still return a valid type name. I suggest to return something like $1, what makes it clear that this is an anonymous type. Or maybe 'Anonym_Object'. I don't think this is a common scenario, and opt for a simple solution.
Interesting thought... I was leaning to us being consistent with our error messages. e.g. public class X { static <T> T[] toArray(T t) { return null; } public static void main(String[] args) { int i = toArray(new Object(){}); } } cannot convert from new Object(){}[] to int
Created attachment 65052 [details] Proposed fix and regression tests
Fix and tests released for 3.3M7 in HEAD.
Created attachment 65184 [details] Small adjustement on top of previous patch This fixes the case where the type signature is included in another signature (e.g. a method signature). Will be in build > I20070427-0010
Verified for 3.3 M7 using build I20070427-0010
*** Bug 99627 has been marked as a duplicate of this bug. ***
