Bug 218167 - Using declare @field crashes AspectJ compiler in certain circumstances
Summary: Using declare @field crashes AspectJ compiler in certain circumstances
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 critical (vote)
Target Milestone: 1.6.0 M2   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-07 09:31 EST by Andrzej Wasylkowski CLA
Modified: 2008-02-07 12:02 EST (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 Andrzej Wasylkowski CLA 2008-02-07 09:31:12 EST
This program:

@interface A {}

aspect Test {
        declare @field : @A int var* : @A;
        declare @field : int var* : @A;

        interface Subject {}
        
        public int Subject.vara;
        public int Subject.varb;
}

class X implements Test.Subject {
}

results in AspectJ compiler crashing (the command: ajc -1.5 Test.java) with java.util.NoSuchElementException exception. The reason for this is that one of the loops in the weaveAtFieldRepeatedly method in the org.aspectj.weaver.bcel.BcelClassWeaver class iterates through one list, but calls "hasNext" on an iterator of another collection: the line

for (Iterator iter2 = worthRetrying.iterator(); iter.hasNext();) {

should be replaced with the line

for (Iterator iter2 = worthRetrying.iterator(); iter2.hasNext();) {

This fix causes AspectJ to correctly process the program above. The bug was reproduced by me on the 1.5.3 version, but it's present in all newer versions as well, including the development version. I didn't look at earlier versions, however.
Comment 1 Andrew Clement CLA 2008-02-07 12:02:15 EST
test and fix are in (thanks!).  I also changed the message that is produced in this case (that you can't doubly annotate a field) since it revealed the mangled member that hosted the annotations rather than the source declaration that led to the mangled member.

Fix will be in next dev build, later today.