Summary: | [plan] [generics] Compiler fails to report name clash for generics violation via ITD | ||||||
---|---|---|---|---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Andrew Eisenberg <andrew.eisenberg> | ||||
Component: | Build | Assignee: | aspectj inbox <aspectj-inbox> | ||||
Status: | NEW --- | QA Contact: | |||||
Severity: | major | ||||||
Priority: | P2 | CC: | aclement | ||||
Version: | unspecified | ||||||
Target Milestone: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Bug Depends on: | |||||||
Bug Blocks: | 255848, 257437 | ||||||
Attachments: |
|
Description
Andrew Eisenberg
2009-01-23 17:57:26 EST
Created attachment 123608 [details]
Project that exhibits this behavior
yikes... is that really the smallest testcase you have... there are two source folders and umpteen types... when only 4 things are involved it seems (the interface, the implementor, the aspect and the other bound, Type1). Here is a much simpler file with the same behaviour: --- import java.util.*; interface I { public <T> List<T> getStuff(); } class C<D extends Set> implements I { public <T extends D> List<T> getStuff(){ return new LinkedList<T>(); } } aspect X { public <T> List<T> I.getStuff(){ return new ArrayList<T>(); } } --- This should actually be a compile time error, there is no missing relationship because it should not compile. If you had looked with javap -private on the GenericMethodImpl you'd see that the compile did not include the variant of the method that returns an ArrayList in the woven target class - although an erroneous weavinfo message will come out if you use -showWeaveInfo. (I suspect indicating a match occurred but not a weave) You cannot have two methods in the target type with the same erasure, it is a name clash - exactly as attempted in this pure java program: --- import java.util.*; interface I { public <T> List<T> getStuff(); } class P implements I { public <T> List<T> getStuff() { return new LinkedList<T>();} } class C<D extends Set> extends P { public <T extends D> List<T> getStuff(){ return new LinkedList<T>(); } } --- Generic ITDs 1\src\Y.java:12 [error] Name clash: The method getStuff( ) of type C<D> has the same erasure as getStuff() of type P but does not override it public <T extends D> List<T> getStuff(){ ^^^^^^^^ 1 error And if the ITD can manage to get onto an intermediate class in the hierarchy: --- import java.util.*; interface I { public <T> List<T> getStuff(); } class P implements I {} class C<D extends Set> extends P { public <T extends D> List<T> getStuff(){ return new LinkedList<T>(); } } aspect X { public <T> List<T> I.getStuff(){ return new ArrayList<T>(); } } --- this reports the same name clash. So the bug is that if the top-most implementor contains an name clash there should be a name clash compilation error. bug is around ResolvedType.compareToExistingMembers() since that checks, when an intertype decl is added to a topmost implementor, whether the new member clashes with an existing one. testcode committed for this - commented out in Ajc164tests unsetting the target field which is currently set for something already released |