Re: [aspectj-dev] Use of non-statically resolvable pointcut designators

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

> ...but I couldn't find it clearly stated
> anywhere.

It's documented in the semantics appendix to the programming guide;
see "Staticly determinable pointcuts"

http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/aspectj-home/doc/progguide/semantics-declare.html#d0e6499

Anything of note should be in the semantics or limitations appendices
or be in Buzilla with the keyword "info".

Wes

Adrian Colyer wrote:
> As a follow-up - Andy & I went searching all through our docs looking for 
> the place where we say that you can only use statically evaluable 
> pointcuts in declare eow statements, but I couldn't find it clearly stated 
> anywhere. (I half recall seeing a list that said "You can only use the 
> following pcds..." but if it's there, I couldn't find it).
>
> I think the simplest thing for users to understand is a compilation error 
> if any of this, target, args, cflow, cflowbelow or 'if' are used in the 
> pointcut expression associated with a deow. But, this might break many 
> existing programs that are currently "getting away with it." 
>
> The next best option seems to me to be to emit a compiler warning saying 
> that "xxx pcd cannot be used in declare error or warning statements and 
> will be ignored." (And then of course, make sure that we really do ignore 
> it). Given our current position, this is possibly what we should do for 
> 1.2 (leaving us the option to make it an error in 1.3 once programs have 
> been tidied up perhaps?).
>
> Both of these options have the drawback of not supporting some deow tests 
> that would have succumbed to full static evaluation. If that's important 
> enough, we could consider warning only when a non-statically determinable 
> situation occurs - but what I dislike about this option is that this can't 
> be determined when compiling the aspect, but only during shadow matching 
> (which could be at a completely different time if e.g. you are binary 
> weaving). 
>
> So I think at the moment I'm leaning towards:=
> 1) making the docs clearer about exactly which pcds are supported for 
> deow, and
> 2) following a warn-and-ignore strategy for violations of that policy
>
> Open to counter-arguments though...
>
> -- Adrian
> Adrian_Colyer@xxxxxxxxxx
>
>
>
>
> Andrew Clement/UK/IBM@IBMGB
> Sent by: aspectj-dev-admin@xxxxxxxxxxx
> 23/02/2004 16:16
> Please respond to aspectj-dev
>  
>         To:     aspectj-dev@xxxxxxxxxxx
>         cc: 
>         Subject:        [aspectj-dev] Use of non-statically resolvable 
> pointcut designators in declare error/warning.
>
>
>
> Hi, 
>
> I'm looking at a bug on this - and I noticed someone else mailed 
> the list on a similar topic earlier today. 
>
> Eric Bodden reported a problem with using if() in a declare 
> warning/error message.  This was a ClassCastException - which of 
> course I'll fix - but it made me think more about what our 
> position is on allowing users to use pointcuts that can't 
> be wholely resolved at compile time with the declare error/warning 
> mechanism. 
>
> At the moment, if a pointcut cannot be entirely statically 
> evaluated then it will behave as if it has matched and the error 
> or warning message will be produced.  I don't think this is 
> quite what we want. 
>
> However, it is not clear whether we should be flagging an 
> error if any of the designators that exhibit this behavior 
> are used against declare error/warning or if we should be 
> flagging an error/warning if it just the case that the entire 
> pointcut cannot be completely resolved statically.  There are 
> some designators that *could* lead to runtime tests but might 
> not if there is enough static info around.  For example 
> target()/this() may or may not create an instanceof test for 
> execution at runtime depending on what the compiler can 
> determine statically. 
>
> So, we have the options: 
>
> Error/Warning if we see a declare error/warning statement whose 
> pointcut uses any of the designators that *might* 
> lead to dynamic residue. 
>
> Error/Warning if we see a declare error/warning statement whose 
> pointcut cannot be completely statically evaluated. 
>
> Any comments? 
> Andy. 
> --- 
> Andy Clement 
> AJDT/AspectJ Development