Summary: | [comp-upgrade] AspectJ compiler requires dependencies the JDT compiler doesnt | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Matt Chapman <mpchapman> |
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | aclement, boehm |
Version: | 1.5.0 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Matt Chapman
2006-03-17 06:50:49 EST
I had a similar problem with a "declare precedence" statement in one of my examples. During a talk with my students I tried to provocate an error message with the statement declare precedence : *, CopAspect, *; But no error message appears. Next I tried to reproduce the bug, export the project and import it as new project into a new workspace. Here AJDT marks the declare statement correct as error. I tried different other things but did not succeed in reproducing this behaviour so at last I deleted all my other projects and puts the problematic example together with the workspace to http://www.javatux.de/aj/examples_with_workspace.tgz (ca. 2 MB) I looked also in .classpath and .project if there are strange entries because it's an older project but can't find any anomalies. Still occurs with AJDT 1.4.0.20060509123512 on Eclipse 3.2RC3. My test project is org.eclipse.ajdt.ui.tests from AJDT. As Matt says - there are two problems here. 1. compilation error never gets reported by AJDT as the compiler never reported that it had compiled the file 2. why does the compiler require that type when the JDT compiler does not. The first one (the really serious one...) is now fixed. There are a class of errors in the compiler that occur at a point so far from the logic that knows what source file is being processed that they just get attached as an error to an AbortException that is thrown - because the compiler can't attach them to the compilationresult for what it is processing at the time. There is some logic that runs after processing a unit and before ending compilation of the units that repairs the damage, attaching the problem from the abortexception to the unit that was being processed at the time. In order to fix this problem a few things got changed: a. changed the 'after() returning: process()' advice in the CompilerAdapter aspect to 'after(): process()' advice which ensures we put out the 'compiled:' message indicating compilation was attempted (to keep AJDT happy). This causes the error to appear in the problems view. b. added some extra code in the code that runs after compilation to double check whether errors exist against the units compilation result. This double checking logic is required because of the code that takes the problem attached to the exception and puts it on the compilation result - previously we only checked for errors in the after process logic. Now that we also check for errors at the end of compilation we correctly *stop* and *dont weave* in the case where this kind of error has occurred. I am half convinced that the fact that AJ thinks we need this type whereas the JDT says we dont (problem 2) is due to an Eclipse compiler difference between 3.1 (what AJ is based on) and 3.2 - so I'll mark this bug as one to double check when the 3.2 compiler is integrated. needs checking, might be fixed now we are a 1.6 compiler |