Bug 234933 - SuppressAJWarnings declared on aspect not applying internally
Summary: SuppressAJWarnings declared on aspect not applying internally
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: unspecified   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P4 normal (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-30 16:25 EDT by Andrew Eisenberg CLA
Modified: 2013-06-24 11:03 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Eisenberg CLA 2008-05-30 16:25:06 EDT
The SuppressAJWarnings annotation is not being applied inside the aspect declaration here.. There is a warning on the declare parents statement, but there shouldn't be.

package p1;

import org.aspectj.lang.annotation.SuppressAjWarnings;

@SuppressAjWarnings
public aspect AddsSerializable {
  declare parents : p2.ToBeSerializable implements java.io.Serializable;
}
Comment 1 Andrew Clement CLA 2008-06-11 17:43:46 EDT
Couldn't remember which xlint was triggered here that needed ignoring, so I looked at the adviceDidNotMatch xlint, which I know obeys suppression if the advice is annotated.  It turns out that also ignores suppression specified at the type level - so I have fixed that case.  There is a new method in org.aspectj.weaver.bcel.Utility that takes a member and a lint key and will check suppression on the member and then on the declaring type of the member.  So this now works for adviceDidNotMatch.  But it needs to be done for all the xlint messages everywhere, and that is not something i want to tackle now - so deferring the rest of it to 1.6.2 but at least in 1.6.1 I've added a useful option for hiding multiple adviceDidNotMatch messages when building a library aspect.
Comment 2 Andrew Clement CLA 2008-12-01 12:42:50 EST
Utility is now on the 'wrong side' of the matcher/weaver split and isn't available for access from some places where lint messages are fired off.  Also, some messages are produced by elements that don't know the related declaring member where they came from or even their declaring type.  This makes determining what to ask about suppression quite difficult.  Upgrading the infrastructure to know who to ask for this information is not trivial - not going to be in 1.6.3.

As an example, in the case of the original bug report, that was probably the xlint invalidAbsoluteTypeName (at a guess) - and that requires WildTypePattern objects to know where they were declared.

Comment 3 Andrew Clement CLA 2013-06-24 11:03:08 EDT
unsetting the target field which is currently set for something already released