InternalCompilerException when generic role has a private field

[stephan]

If a generic role has a private field the following exception occurs during compilation:

org.objectteams.otdt.core.exceptions.InternalCompilerError: You
discovered a bug in the ObjectTeams/Java Development Tooling.
Please mail this stacktrace and a description how to reproduce the bug
to topprax-devel at first.fraunhofer.de
Thank you -- the OTDT Development Team.
Method not applicable on this type
        at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.addMethod(ReferenceBinding.java:303)
        at org.objectteams.otdt.core.compiler.util.AstConverter$1.beforeMethodLookup(AstConverter.java:600)
        at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:593)
        at org.eclipse.jdt.internal.compiler.ast.ReturnStatement.resolve(ReturnStatement.java:221)
        at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:714)
        at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:266)
        at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:654)
        at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1788)
        at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1887)
        at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:694)
        at org.objectteams.otdt.core.compiler.control.Dependencies.establishUnitState(Dependencies.java:342)
        at org.objectteams.otdt.core.compiler.control.Dependencies.ensureState(Dependencies.java:258)
        at org.objectteams.otdt.core.compiler.control.Dependencies.ensureState(Dependencies.java:250)
        at org.objectteams.otdt.core.compiler.control.Dependencies.ensureState(Dependencies.java:250)
        at org.objectteams.otdt.core.compiler.control.Dependencies.ensureState(Dependencies.java:250)
        at org.objectteams.otdt.core.compiler.control.Dependencies.ensureState(Dependencies.java:250)
        at org.objectteams.otdt.core.compiler.control.Dependencies.ensureState(Dependencies.java:213)
        at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:949)
        at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1003)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder._OT$process$orig(CompilationUnitProblemFinder.java:213)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder._OT$process$chain(CompilationUnitProblemFinder.java)
        at org.objectteams.otdt.compiler.adaptor.AdaptorActivator._OT$CompilationUnitProblemFinder$activateChecker$base(AdaptorActivator.java)
        at org.objectteams.otdt.compiler.adaptor.AdaptorActivator$__OT__CompilationUnitProblemFinder.activateChecker(AdaptorActivator.java:276)
        at org.objectteams.otdt.compiler.adaptor.AdaptorActivator._OT$CompilationUnitProblemFinder$activateChecker$process(AdaptorActivator.java:270)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder._OT$process$chain(CompilationUnitProblemFinder.java)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java)
        at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:274)
        at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:190)
        at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
        at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:709)
        at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:770)
        at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1253)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:124)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
        at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:149)
        at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
        at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:102)
        at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
        at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)

This problem is witnessed by this new test: A.1.14-otjld-generic-role-1

Reported via email by Ivica Lončar

[stephan]

At a closer look several issues need to be solved:

1. Fix the reported exception (should be easy)
2. Fix a few more issues to make the test pass.
3. Clarify in OTJLD what restrictions apply to generic roles.

Discussion regarding item 3.:

After generic base classes had to be ruled out (cf. OTJLD §2.1.2(e)) we are speaking about examples of this kind:

1  public team class  MyTeam {
2    protected class MyRole<T> playedBy MyBaseClass {
3      void rm() { ... }
4      void rm() <- after void bm(); // RAW TYPE MyRole!
5    }
6    protected class PlainRole playedBy OtherBaseClass {
7      void receiveRole(MyRole<String> r) { ... }
8      void recieveRole(MyRole<String> r) <- after void processBase(MyBaseClass b);
9    }
10   void teamMethod(MyBaseClass as MyRole<String> r, MyBaseClass b) {
11     MyRole<Date> otherRole = new MyRole<Date>(b);
12   }
13 }

Rules have to make sure, that every instantiation of MyRole substitutes the parameter T with a real type. Let's distinguish these cases

• Explicit creation using role constructor (line 11) - OK.
• Declared lifting (line 10) - OK.
  (cannot allow MyBaseClass as MyRole - is a raw type).
• Lifting of callin parameter, callout return (e.g., line 8) - OK
• Lifting call target in callin binding (line 4): NOT OK (missing type argument)

We could still allow raw types and just issue a warning, but since these uses occur in the very context where the generic role is defined, admitting raw types here seems to undermine the original intentions of generics.

Thus, it seems we cannot accept callin bindings in generic role class. This is unfortunate, but unavoidable.

[stephan]

The exception is fixed in r19454.

Remain some bogus compile errors from places where the compiler "forgets" about the type parameter.

[stephan]

Test is in A.1.14-otjld-generic-role-1.

Further required fixes are in r19455.

The more fundamental issues has been spawned into #192.

Fixes will be included in next build on http://www.objectteams.org/distrib/otdt-updates-unstable