Community
Participate
Working Groups
If a compilation unit contains several toplevel team classes (of which obviously only one can be public) several exceptions have been observed: java.lang.ArrayIndexOutOfBoundsException: 4324 at org.eclipse.jdt.internal.compiler.classfmt.ClassFileStruct.u1At(ClassFileStruct.java:57) at org.eclipse.objectteams.otdt.internal.core.compiler.bytecode.ConstantPoolObjectReader.getConstantPoolEntryType(ConstantPoolObjectReader.java:118) at org.eclipse.objectteams.otdt.internal.core.compiler.bytecode.ConstantPoolObjectReader.access$0(ConstantPoolObjectReader.java:116) at org.eclipse.objectteams.otdt.internal.core.compiler.bytecode.ConstantPoolObjectReader$1.hasNext(ConstantPoolObjectReader.java:685) at org.eclipse.objectteams.otdt.internal.core.compiler.bytecode.BytecodeTransformer.copyAllNonWideConstants(BytecodeTransformer.java:648) at org.eclipse.objectteams.otdt.internal.core.compiler.bytecode.BytecodeTransformer.checkCopyNonWideConstants(BytecodeTransformer.java:129) and also: org.eclipse.objectteams.otdt.core.exceptions.InternalCompilerError: You discovered a bug in the Object Teams Development Tooling. Please consider filing a bug including this stacktrace and a description how to reproduce at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Objectteams Thank you -- the OTDT Development Team. Class file was not yet written to disk at org.eclipse.objectteams.otdt.internal.core.compiler.model.RoleModel.getByteCode(RoleModel.java:370) at org.eclipse.objectteams.otdt.internal.core.compiler.bytecode.BytecodeTransformer.checkCopyNonWideConstants(BytecodeTransformer.java:102) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:972) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:1132) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:985) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:1139) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.generateCode(CompilationUnitDeclaration.java:424) at org.eclipse.objectteams.otdt.internal.core.compiler.control.Dependencies.establishUnitState(Dependencies.java:360) at org.eclipse.objectteams.otdt.internal.core.compiler.control.Dependencies.ensureState(Dependencies.java:260) at org.eclipse.objectteams.otdt.internal.core.compiler.control.Dependencies.ensureUnitState(Dependencies.java:409) at org.eclipse.objectteams.otdt.internal.core.compiler.control.Dependencies.ensureTeamState(Dependencies.java:630) at org.eclipse.objectteams.otdt.internal.core.compiler.statemachine.copyinheritance.CopyInheritance.copySyntheticTeamMethods(CopyInheritance.java:1118) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:926) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:1132) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:985) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:1139) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.generateCode(CompilationUnitDeclaration.java:424)
Created attachment 170236 [details] several fixes Test CompilationOrder.testB22_twoToplevelTeams2() witnesses some problems, but the AIOOBE could only be reproduced in the IDE. Fixes are based on the following findings: - MethodModel could use inconsistent pair of (constant pool) offsets and bytes. This happened when the array of offsets was reused from another class with more constant pool entries. Thus the bytes array was indexed with a too large index -> AIOOBE. Fixed by always respecting ConstantPool.currentIndex as the length of offsets - RoleModel could try to retrieve a class file from disk in a state where the ClassFile was created but not yet written to disk. Fixed by retrieving class bytes via the CompilationResult (this also an optimization). - I observed attempts to generateCode types from the same CU out of order, due to re-entrance via Dependencies. Fixed by marking the translation state at the end of TypeDeclaration.generatedCode. This fixes the ICE. - additional issues in BytecodeTransformer: - if dstType is already a team don't travel to enclosing type - ensure srcModel & method.declaringClass match
Patch has been committed as r379.
verified for M3 using 201005282024
