Bug 176933 - [plan] [deow] declare warning change not picked up on incremental compile
Summary: [plan] [deow] declare warning change not picked up on incremental compile
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: DEVELOPMENT   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-11 00:51 EST by Ron Bodkin CLA
Modified: 2013-06-24 11:04 EDT (History)
1 user (show)

See Also:


Attachments
Sample AJDT project showing incremental compilation failure. (29.75 KB, application/zip)
2007-03-11 00:53 EST, Ron Bodkin CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ron Bodkin CLA 2007-03-11 00:51:30 EST
In the attached self-contained example project, if you uncomment the declare warning line, AspectJ HEAD erroneously performs an incremental build:

public aspect RemoteErrorHandling {
	//declare warning: handler(RemoteException): "handling remote exception";
}

Build output:
21:42:27 ===========================================================================================
21:42:27 Build kind = AUTOBUILD
21:42:27 Project=MusicOnline, kind of build requested=Incremental AspectJ compilation
21:42:27 build: Examined delta - source file changes in required project MusicOnline
21:42:27 Classpath=C:\devel\demo\MusicOnline\bin;C:/Program Files/Java/jre1.5.0_06/lib/rt.jar;C:/Program Files/Java/jre1.5.0_06/lib/jsse.jar;C:/Program Files/Java/jre1.5.0_06/lib/jce.jar;C:/Program Files/Java/jre1.5.0_06/lib/charsets.jar;C:/Program Files/Java/jre1.5.0_06/lib/ext/dnsns.jar;C:/Program Files/Java/jre1.5.0_06/lib/ext/localedata.jar;C:/Program Files/Java/jre1.5.0_06/lib/ext/sunjce_provider.jar;C:/Program Files/Java/jre1.5.0_06/lib/ext/sunpkcs11.jar;C:/eclipse/plugins/org.aspectj.runtime_1.5.4.200701151324/aspectjrt.jar;C:/eclipse/plugins/org.junit_3.8.2/junit.jar;
21:42:27 Preparing for build: planning to be an incremental build
21:42:27 Starting incremental compilation loop 1 of possibly 5
21:42:27 AJC: compiling source files
21:42:27 Timer event: 203ms: Time to first compiled message
21:42:27 AJC: compiled: C:\devel\demo\MusicOnline\src\repository\service\delegate\RemoteErrorHandling.aj
21:42:27 AJC: processing reweavable state
21:42:27 AJC: adding type mungers
21:42:27 Timer event: 203ms: Time to first woven message
21:42:27 AJC: woven aspect repository.service.delegate.RemoteErrorHandling (from C:\devel\demo\MusicOnline\src\repository\service\delegate\RemoteErrorHandling.aj)
21:42:27 Examining whether any other files now need compilation based just compiling: '{C:\devel\demo\MusicOnline\src\repository\service\delegate\RemoteErrorHandling.aj}'
21:42:27 AspectJ reports build successful, build was: INCREMENTAL
21:42:27 AJDE Callback: finish. Was full build: false
21:42:27 Timer event: 203ms: Total time spent in AJDE
21:42:27 Timer event: 0ms: Create element map (330 rels in project: MusicOnline)
21:42:27 Types affected during build = 1
21:42:27 Timer event: 16ms: Add markers (40 markers)
21:42:27 Timer event: 281ms: Total time spent in AJBuilder.build()
Comment 1 Ron Bodkin CLA 2007-03-11 00:53:10 EST
Created attachment 60514 [details]
Sample AJDT project showing incremental compilation failure.
Comment 2 Ron Bodkin CLA 2007-03-11 01:03:16 EST
If you change the declare warning to the following it works:

	declare warning: call(* *(..) throws RemoteException): "calling remote"; 

However, if you try to change just the text of the warning, the problems are not updated with an incremental build (you need to clean and rebuild).

I would like the old AJDT build button back. 50% of my builds are now done with the painful clean & rebuild process since even if I turn off build automatically I still get failing incremental builds quite frequently.
Comment 3 Andrew Clement CLA 2008-03-24 20:20:12 EDT
the problem here is that the DeclareWarning shadow munger is built early on in the process, unlike the other advice shadow mungers.  So the normal checks about what has changed in CrosscuttingMembers.replaceWith() aren't quite right, it doesn't see the shadow munger as new by the time the method is called.  I think we will have to special case for this kind of shadow munger.
Comment 4 Andrew Clement CLA 2013-06-24 11:04:13 EDT
unsetting the target field which is currently set for something already released