Bug 122801

Summary: circular-pointcut message when redefining/reusing pertarget pointcut
Product: [Tools] AspectJ Reporter: Wes Isberg <wes>
Component: CompilerAssignee: aspectj inbox <aspectj-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P2    
Version: 1.5.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Wes Isberg CLA 2006-01-05 15:10:53 EST
I get a message about a circular pointcut definition when reusing the superaspect definition in a subaspect redefinition (override), but only if the aspect is declared pertarget on that pointcut.  At a minimum we need to decide if the pointcut referred to in the superaspect pertarget clause should resolve to the superaspect pointcut or the subaspect pointcut.  I'm inclined to use the overridden pointcut if the pointcut reference is unqualified, in order to support binary library aspects.  Conversely, library aspect writers who want to avoid overriding should be able to use a static reference to the library aspect, e.g.,

   abstract aspect Foo pertarget(Foo.pc()) { ...

(which would be an error if pc() is itself abstract). More (but not entirely) formally, a reference of the form Foo.pc() is resolved by looking in Foo and supertypes for a poincut pc, while an implicit reference of the form "pc()" is resolved by using the most-concrete type and then up the supertypes.

-----------------------------------------------------------------
package bugs;

public class ReuseWhileRedefiningPointcut {
	static void run(){}
	public static void main(String[] args) {
		run();
	}
        // use pertarget clause to see error message
	static abstract aspect Super { //pertarget(voidCalls()){
		pointcut voidCalls() : call(void *(..)) 
			&& within(ReuseWhileRedefiningPointcut);
		before() : voidCalls() {
			System.out.println("here: " + thisJoinPoint);
		}
	}
	
	static aspect A extends Super {
		pointcut voidCalls() : Super.voidCalls() && call(void run());
	}
}
Comment 1 Wes Isberg CLA 2006-05-10 11:31:42 EDT
In AspectJ 1.5.1a (from AJDT), I now get a ClassCastException rather than a compiler error, so I'm hoisting the priority to P2.

Internal compiler error
java.lang.ClassCastException: org.aspectj.weaver.MissingResolvedTypeWithKnownSignature

	at org.aspectj.ajdt.internal.core.builder.AjState.recordClassFile(AjState.java:783)

	at org.aspectj.ajdt.internal.core.builder.AjState.noteResult(AjState.java:636)

	at org.aspectj.ajdt.internal.core.builder.AjBuildManager$3.acceptResult(AjBuildManager.java:884)

	at org.aspectj.ajdt.internal.compiler.AjCompilerAdapter.afterProcessing(AjCompilerAdapter.java:206)

	at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$afterReturning$org_aspectj_ajdt_internal_compiler_CompilerAdapter$4$6b855184(CompilerAdapter.aj:90)

	at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:528)

	at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:329)

	at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:862)

	at org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild(AjBuildManager.java:269)

	at org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild(AjBuildManager.java:168)

	at org.aspectj.ajde.internal.CompilerAdapter.compile(CompilerAdapter.java:117)

	at org.aspectj.ajde.internal.AspectJBuildManager$CompilerThread.run(AspectJBuildManager.java:191)

Comment 2 Andrew Clement CLA 2006-05-30 10:29:10 EDT
I believe the classcast at that line is fixed (cant remember under which bug we did it though!)
Comment 3 Wes Isberg CLA 2006-05-31 03:43:47 EDT
Verified fix in head just now.  I should have installed test code as test case.