Avoid the need to weave unbound roles

[stephan]

If an unbound role has a callin method with a base call, until 1.2.8 this role class requires weaving by the OTRE in order to create the (mostly empty) base-call surrogate (which throws an OTREInternalError) -- to be overridden by sub-roles with callin bindings to this callin method.

In the OT/Equinox setting we did not detect the need to weave the super-role thus the base-call surrogate was missing at run-time => NoSuchMethodError.

(reported by Coopar)

[stephan]

r20100 provides a quick solution for 1.2.x:

• include unbound roles with callin methods in the CallinRoleBaseBindings attribute (specifying a base class "<none>") (kind-of abusing this attribute)

[stephan]

r20107 implements a new strategy for 1.3.x, where empty (throwing) base-call surrogates are indeed generated by the compiler, not the OTRE:

OTRE:

• don't create empty base-call surrogates for unbound roles
• do replace existing empty surrogates if existent

Compiler:

• new class SyntheticBaseCallSurrogate: directly generate 'throw'ing code
• if callin is unbound: manually resolve calls to above synth method
• be careful not to override a meaningful surrogate with an empty one but refer to inherited version in that case
• make BaseCallMessageSend.getBaseCallSurrogate (formerly genBaseCallSurrogate) smarter:
  • transparently handle retrieval and creation of surrogates
  • distinguish binary/source cases
  • add method to class binding if necessary
• defer creation of surrogates until end of mappings resolved to be able to distinguish bound/unbound callin methods.
• during byte-code adjust: if a static surrogate is found in sub-team, call the super-teams surrogate, sub-team may not have a callin binding.

[stephan]

Corrections for r20107 to fix regressions:

• r20109: fix a simple bug in a loop-logic
• r20110: prevent strengthening of surrogate signatures during copy-inheritance to ensure that OTRE-generated methods will indeed replace compiler-generated placeholders
• r20111: account for generalized return type: cast to the box-type to prepare for implicit unboxing (in contrast to AST-based variant here we generate the cast directly from !generateCode()).

[stephan]

With a further fix in r20115 plus new tests 4.5.2-otjld-unbound-base-call-1, 4.5.2-otjld-unbound-base-call-2, and 4.5.1-otjld-single-base-call-6 I consider this issue resolved.