Bug 154690

Summary:

adviceDidNotMatch warning not added on incremental compile

Product:

[Tools] AspectJ

Reporter:

Helen Beeken <hlhawkins>

Component:

Compiler

Assignee:

aspectj inbox <aspectj-inbox>

Status:

NEW ---

QA Contact:

Severity:

normal

Priority:

CC:

aclement

Version:

DEVELOPMENT

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
failing testcase to reproduce the problem	none

Description Helen Beeken

2006-08-22 09:09:01 EDT

Commenting out a matched method-call that should result in an adviceDidNotMatch warning does not produce the xlint warning on an incremental compile. Doing a full build produces the warning.

Comment 1 Andrew Clement

2006-08-22 09:12:04 EDT

probably related to changes under 152589

Comment 2 Helen Beeken

2006-08-22 09:12:18 EDT

Created attachment 48367 [details]
failing testcase to reproduce the problem

Apply this patch to the tests project.

Comment 3 Andrew Clement

2006-08-24 04:26:23 EDT

Ignore my previous comment, I don't think it is related.  The problem is that advice contains a flag 'hasMatchedAtLeastOnce' that records whether the advice has matched anything - when the advice is applied to a shadow, the flag flips to true.  Reporting this warning is a matter of going through all the advice post weave and if any advice has the flag still at false then report the 'advice did not match' problem.

The flag is never flipped back to false - so if on an incremental compile you remove what was a match and our 'smart' incremental compiler just compiles/weaves that single file - then the flag is still in the 'true' state.  Advice won't be rebuilt unless the aspect is recompiled.  Forcing the flag to false again before weaving isn't right as maybe it is still going to be matching in some other type that you aren't compiling/weaving on this incremental compile.

Hacky options that spring to mind include recording in the bceladvice the list of types the advice did apply to - we can then be smarter when determining whether to put out the message, since we will be able to determine whether the files we are now compiling are the only ones it did apply to and it no longer applies.  *but* I don't like the thought of a potentially very large list of types being stored in each advice - it could consume a large amount of heap.