Reports for loops which iterate over collections or arrays, and can be replaced with an enhanced for loop (i.e. the foreach iteration syntax).
Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>
If an anonymous class calls a method ITD'd onto one of its own
supertypes (e.g. new A() { xx(null); }) then it can be reported
as an ambiguous method invocation on Java8. There is different
handling for Java8 that is revealing an issue. The intertype
method declarations are recorded in a member finder attached to the
target type (A in this case). When the local type binding is
built it gets all the methods from supertypes added to it - this
unfortunately includes the ITD method. Then later when something
asks for all 'xx' methods on A, it finds the ITD method from when
A was constructed and an additional copy from the member finder.
The quick fix is for the member finder to use a set rather than
list when answering 'what are the xx methods'. If this proves
a problem down the line the deeper fix would be to avoid including
ITDs when the local type binding is built.
genericitds: when the compiler asks for a member that is in fact from an ITD on a generic type, we fix up the field and return it parameterized for the particular type.
This is the beginning of a significant refactoring needed to cleanly support generics. We need to be much crisper about when we have an unresolved type (plain old TypeX) and when we have a resolved type. This refactoring renames TypeX to UnresolvedType and ResolvedTypeX to ResolvedType. In addition, it moves a number of methods that were defined on TypeX but which can only be answered by resolved types down onto ResolvedType. At the moment, ResolvedType still extends UnresolvedType - but a ResolvedType is *not* a UnresolvedType and this inheritance of convenience will be broken down the line so that ResolvedType does not extend UnresolvedType. Full signature information can only be known for ResolvedTypes.
Lars Grefer
Andy Clement
aclement