Community
Participate
Working Groups
Get compiler xlint adviceDidNotMatch when using parameterized type to specify type pattern for pertypewithin clause. Parameterized type works in pointcuts, and the pointcut matches staticly (with deow). Same result for before or around advice. Also, the permitted uses for the type parameter of a parameterized aspect in the adk15notebook section on point. Resolutions could be: - not a bug b/c the code below is wrong - not permitted to use type parameter in pertypewithin; doc updated - permitted, fixed ... AspectJ version 1.5.0.20051206103951, via AJDT ----------------------------------------- sample package bugs; public class GenericPerTypeWithin { public static void main(String[] args) { new C(); // fyi, compiler does nothing absent this call? } public static abstract aspect Singleton<Target> pertypewithin(Target) { pointcut creation() : execution(Target+.new()) ; // adviceDoesNotMatch - same for before advice Target around() : creation() { return proceed(); } // picks out constructor-execution below declare warning : creation() : "Singleton.creation()"; } static class C { C(){} } static aspect A extends Singleton<C> {} }
Bah!!!! I've fixed this - and my fix is great. but it breaks an incremental compilation test ... the reason is that the incremental test aspect now matches where it didnt before (it used a generic pertypewithin). It relates to bug 115251 which is where Adrian was investigating changes to abstract aspects during incremental compilation. He put some stuff in, then commented it out - if I uncomment it then my pertypewithin fix works, but other tests fail ...
here be dragons.... (and it's 1am, and I need to go to bed...). That abstract aspect fix I tried to put in and then backed out again really does need to happen to be solid in all cases. But as you discovered.... it has knock-on consequences that seemed unpleasant when I pulled on it (I was getting a 1.2.1 compatability test failure amongst other nasties). If you can find a clean way to include the absract aspect fix though, it's the right thing to do...
Right. I have fixed this properly. the abstract aspect fix is in. the cflow optimizations are sorted (and more bullet proof than before) and pertypewithin(TypeVariable) works. 1. ReferenceType.getPerClause() needed to parameterize what it was returning when necessary. 2. EclipseSourceType.getPerClause() needed to return something intelligible when it could, rather than defaulting to PerSingleton(). It now looks on the aspect declaration and returns the right thing. 3. CrosscuttingMembersSet.addOrReplaceAspect(). I've uncommented Adrians stuff to handle abstract aspects. The problem is that addOrReplace.. was running twice - once during compile time, once during weave time. The type mungers to add the cflow counters were put into the crosscutting set whilst resolving the pointcuts the first time through addOrReplace. When the second addOrReplace occurs - the type mungers are deleted, and they never get readded because the fields are cached in the CflowPointcut logic (for reuse). The fix is that if we are trashing the type mungers, we need to trash the CflowPointcut cache - causing things to be recreated correctly. (Whether we need to call addOrReplaceAspect twice - compile time and weave time - i didnt investigate). 4. Finally, the logic in cflowpointcut for caching and reusing stacks/counters was a little shaky and I think could break if you used the same pointcut in two different aspects (because it maintained a cache of pointcut>cflowfield). Depending on the order in which ajc saw the aspects, the field might go into one aspect or the other - real problem for separate compilation. The real fix is to include the aspect name in the key for the cache - so we only share stacks/counters if a cflow entry pointcut is reused within the same aspect. i will check this in shortly. should help with incremental bugs relating to abstract aspects!
fixes checked in.
fix available.
fyi, my original code for this bug (and some other code) now produces VerifyError when no-inline is on with the released AspectJ 5. I'm still isolating test cases, but as a workaround users should use the compiler's default inline setting.
