Community
Participate
Working Groups
Observed in the context of bug 417675 : Consider the following Java classes: class C<T> { class D { } } class E extends C<String> { } A reference 'E.D' is equivalent to the type reference 'C<String>.D' but since JvmTypeRefernces in Xtype are modelled as plain x-refs with a qualified name, we loose this information when using 'E.D' in Xtend code. The IJvmTypeProvider is queried with 'E.D' and should return a JvmType which is the raw type C.D. From that one, it cannot be deduced which value should be bound to the free type variable T even though the concrete syntax provided that information.
Possible solution / workaround: When resolving an inner JvmParamterizedTypeReference via a subtype of the declaring type, keep the concrete syntax ('E.D' in the example) or the subtype information as an adapter / structural feature so that a proper LightweightTypeReference can be created from that by inspecting this information.
see ignored tests in SuperTypeTests.xtend
Not 2.8