Bug 115252 - want xlint message for improper annotation type
Summary: want xlint message for improper annotation type
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: 1.5.0M4   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: 1.5.0RC1   Edit
Assignee: Helen Beeken CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-06 22:10 EST by Wes Isberg CLA
Modified: 2012-04-03 16:14 EDT (History)
0 users

See Also:


Attachments
testcase patch (18.50 KB, patch)
2005-11-17 08:53 EST, Helen Beeken CLA
no flags Details | Diff
zip containing fix (5.08 KB, application/zip)
2005-11-17 08:57 EST, Helen Beeken CLA
no flags Details
updated testcase patch (20.97 KB, patch)
2005-11-18 09:26 EST, Helen Beeken CLA
aclement: iplog+
Details | Diff
zip containing updated proposed fix (6.31 KB, application/zip)
2005-11-18 09:31 EST, Helen Beeken CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wes Isberg CLA 2005-11-06 22:10:08 EST
When an annotation can only target one kind of thing (e.g., a type) but is used
to modify something else in a pointcut (e.g., a method), it would be nice if the
compiler emitted an error, since the two situations can be confusingly similar:

   call(@Nice * *(..))      // method
   call((@Nice *) *(..))    // return type


---------------------------------------------
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

public class AnnotationTypePatternMistakes {
	@Retention(RetentionPolicy.RUNTIME)
	@Target({ElementType.TYPE}) 
	@interface I{}
	@I()
	class C{}
	static aspect A {
		// would like a CE here - I only on types
		pointcut pc() : execution(@I * *(..));
		declare error : pc() : "hi";
	}
}
Comment 1 Andrew Clement CLA 2005-11-08 03:47:48 EST
take a look... start at WildTypePattern.resolveBindings() which converts all
patterns to concrete ExactTypePatterns in situations like this..
Comment 2 Helen Beeken CLA 2005-11-17 08:34:32 EST
The fix has to go in to SignaturePattern.resolveBindings(..) rather than lower
down because in the case of the annotation pattern being non-null i.e you have a
pointcut of the form

@MyAnnotation * *(..) 

then you need to know the fact that you're interested in methods when you check
whether @MyAnnotation has an @Target annotation which is ElementType.METHOD (if
no @Target is specified then the default is that it applies to everything). 

There is then the cases for incorrect annotation types in the other positions
within the signature pattern, for example

* (@MyAnnotation *).*(..)           - declaring type
* *(@MyAnnotation *)                - parameter type
(@MyAnnotation *) *(..)             - return type
* *.*(..) throws (@MyAnnotation *)  - throws pattern (required)
* *.*(..) throws !(@MyAnnotation *) - throws pattern (disallowed)

In these cases, all that needs to be checked is whether the patternNode has a
@Target annotation on it which is either not the default or not ElementType.TYPE
(as these are the only ones allowed). Again, I believe that the logic should be
contained in the SignaturePattern class rather than lower down because the
different implementations of resolveBindings(..) can be called from various
places and placing a check on the targetKind might result in an xlint warning
being recorded when it shouldn't. Unfortuntately, I can't think of a testcase
for this :-(

The overall fix is to mirror the implementation of working out whether runtime
retention is there by adding a method "String getTargetType()" to the
ReferenceTypeDelegate interface and the corresponding implementations in the
four classes which implement this (excluding the AbstractReferenceTypeDelegate
class). Then, in SignaturePattern.resolveBindings(..) after each PatternNode has
been resolved, check whether it has the correct target kind.

The drawback of putting the fix in SignaturePattern is that not all pointcuts
are resolved via this route, for example 

handler(@TypeAnnotation *)

however, I'm leaving the implementation for these scenarios until someone raises
it as a bug since the proposed fix covers the scenario under which this bug was
raised. I believe though, a similar implementation to the one proposed here
would need to be applied in this case.
Comment 3 Helen Beeken CLA 2005-11-17 08:53:40 EST
Created attachment 30135 [details]
testcase patch

Apply this patch to the tests project.

Note that this fix means that with testAtField_WrongTargetSource() we now get
two xlint messages which has meant that updates have had to be made to the
corresponding place in ajc150.xml.
Comment 4 Helen Beeken CLA 2005-11-17 08:57:33 EST
Created attachment 30136 [details]
zip containing fix 

This zip contains two patches which make up the proposed fix for this bug:

* pr115252-org-aspectj-ajdt-core-patch.txt - apply to the org.aspectj.ajdt.core
project
* pr115252-weaver-patch.txt - apply to the weaver project
Comment 5 Helen Beeken CLA 2005-11-18 09:24:16 EST
The previously attached patches need to be ammended for a couple of reasons.
Firstly, the scenario when an annotation has more than one @Target annotations
isn't covered (which requires updates to both the tests and proposed fixes).
Secondly, it is nicer to deal with AnnotationTargetKind's (which is a newly
created TypeSafeEnum which lives better in its own class rather than as an inner
class) rather than Strings.
Comment 6 Helen Beeken CLA 2005-11-18 09:26:34 EST
Created attachment 30220 [details]
updated testcase patch

Updated testcase patch including one extra test which has annotations that have
more than one @Target annotation.

Apply patch to the tests project.
Comment 7 Helen Beeken CLA 2005-11-18 09:31:05 EST
Created attachment 30222 [details]
zip containing updated proposed fix

Zip containing updated proposed fix as discussed in comment #5.

This zip contains two patches which make up the proposed fix for this bug:

* pr115252-org-aspectj-ajdt-core-patch2.txt - apply to the
org.aspectj.ajdt.core
project
* pr115252-weaver-patch2.txt - apply to the weaver project
Comment 8 Andrew Clement CLA 2005-11-18 10:05:33 EST
patches integrated - thanks Helen.  Waiting on build.
Comment 9 Andrew Clement CLA 2005-11-19 04:53:22 EST
fix available.