Summary: | SuppressAJWarnings declared on aspect not applying internally | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Andrew Eisenberg <andrew.eisenberg> |
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P4 | CC: | aclement |
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | Macintosh | ||
OS: | Mac OS X - Carbon (unsup.) | ||
Whiteboard: |
Description
Andrew Eisenberg
2008-05-30 16:25:06 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. 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. unsetting the target field which is currently set for something already released |