Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 331877 - [compiler][generics] implicit inheritance must apply substitution for type variables from outer scope
Summary: [compiler][generics] implicit inheritance must apply substitution for type va...
Status: VERIFIED FIXED
Alias: None
Product: Objectteams
Classification: Tools
Component: OTJ (show other bugs)
Version: 0.8   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 0.8 M4   Edit
Assignee: Stephan Herrmann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-05 13:54 EST by Stephan Herrmann CLA
Modified: 2010-12-16 17:56 EST (History)
0 users

See Also:


Attachments
initial test & fix (22.60 KB, patch)
2010-12-07 07:50 EST, Stephan Herrmann CLA
no flags Details | Diff
additional test & fix (32.87 KB, patch)
2010-12-11 08:41 EST, Stephan Herrmann CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Herrmann CLA 2010-12-05 13:54:31 EST
In a situation like this

public team class TeamA12grf13_1<U> {
    protected abstract class R {
        protected abstract void test(U u);
    }
}

public team class TeamA12grf13_2 extends TeamA12grf13_1<String> {
    protected class R {
        protected void test(String u) {
            System.out.print(u);
        }
    }
}

implicit inheritance must consider the substitution of type parameter U,
as to detect that test(String) indeed overrides test(U).
Currently, lookup of the inherited signature  test(U) within the scope
of the tsub role gives a MissingType.
Comment 1 Stephan Herrmann CLA 2010-12-07 07:50:50 EST
Created attachment 184713 [details]
initial test & fix

Here's a first test and the implementation to make it work:

- several locations need an extra .original() or .erasure() before 
  comparing elements:
    AllocationExpression, ConstantPoolObjectMapper/Reader, RoleModel,
    CopyInheritance
- when creating parameterized type binding also consider anchor in provided
  type binding for creating a dependent type binding (with parameters)
- ParameterizedTypeBinding.methods() must re-check if the original has 
  methods added since the last call and add more parameterized methods to its
  own methods
- never consider a role type as static, although Java believes all ifc must be
  static. (could not access parameters of the team from a role interface)
- regression fix re ExternalizedRoles.test1610_methodReturnIllegalAnchor3()
  (failed to set ignoreFurtherInvestigation on method with broken return type)
- Avoid casts to RoleTypeBinding if only DependentTypeBinding is required
  (could be WeakenedTypeBinding or a ParameterizedTypeBinding with an anchor)
- Start avoiding _staticallyKnownTeam but use enclosingType() 
  (plays better with parameterized types)
- More effectively avoid strengthening of superclass of __OT__Confinged 
  (cycle!)
- Ensure tsuper link is a parameterized type binding if super team is
  parameterized.
- Never directly create ParameterizedTypeBinding, let LookupEnvironment decide
  what exactly to create (Dependent?)
Comment 2 Stephan Herrmann CLA 2010-12-11 08:41:18 EST
Created attachment 185018 [details]
additional test & fix

With this patch we're actually getting to the real issue:
Applying generic substitution during copy inheritance and callin
transformation.

Types:
- copy inheritance of CallinMethodMappingsAttribute needs to respect 
  generic substitutions (using new helper method in TypeModel and new
  argument in the ModelElement.addOrMergeAttribute() call-chain.
- creating super-ifc link for copy-inheritance must avoid using the erasure
  (from getRealType()), 
  otherwise testA12_genericRoleFeature16a() creates duplicate super interface
  TeamA12grf16_2$Confined.
- mergeSuperinterfaces needs to perform type parameter substitutions
  in order to avoid duplicate super interfaces.

Methods:
- let parameterized method share the MethodModel of their original;
  needed to share, e.g., _callsBaseCtor information

Expressions:
- special care for receiver cast in callin-wrapper:
  don't let type erasure hide the fact that we have an RTB
- generated instanceof expressions must avoid resolving to a parameterized
  type (see testA12_genericRoleFeature16f()). Do so by creating qualified 
  type reference using AstGenerator.typeReference().
Comment 3 Stephan Herrmann CLA 2010-12-11 08:51:19 EST
Open issues as of the previous patch:
 - check whether StaticReplaceBindingsAttribute needs similar translation as
   CallinMethodMappingsAttribute regarding substitutions in method signatures
 - check covariant substitution of role and base type parameters
   relevant for inheritance of callin mappings.
Comment 4 Stephan Herrmann CLA 2010-12-12 18:36:09 EST
Additional fixes are in these commits:

r1147: two small fixes on top of the latest patch

r1158f: Fix regressions:
- testA119_nestedValueParameter2(): 
  better bound-check for mixed value&type parameters
  - transfer valueParamPosition in LookupEnvironment.createParameterizedType()
  - substituteAnchor has to handle combinding parameterized & dependent types
  (includes better readableName and new IProblem)
- testA12_genericRoleFeature13():
  use enclosing's erasure in TeamModel.levelFromEnclosingTeam()
  was: Protections.canBeSeenBy wrongly answered false.

r1162: expect different output after r1159

r1163: expect new IProblem from r1159

r1165: avoid NPE seen in RL (som-cache example):
- ParameterizedTypeBinding.isBinaryBinding() is not meaningful,
  need to look inside (erasure)

r1166: avoid cycles observed in RL (som-cache example):
- never wrap top-confined superclass, this reference is not dynamically bound
- during role strengthening always compare erasure() for identity.

r1168: More tests & fixes
- support generic substitution even of static methods iff following the 
  tsuper link

r1170f: 
- When tsub instantiates type parameters of a tsuper method keep a
  ParameterizedMethodBinding during compilation but erase to the original
  tsuper signature for code gen and byte-code adjust to ensure proper
  overriding.
Comment 5 Stephan Herrmann CLA 2010-12-14 11:18:43 EST
More progress:

r1172f:
Motivated by OTREInternalError "base-call impossible" due to discrepancy 
between compiler & OTRE:
Improve the strategy for parameterized role methods from r1170:
- NPE-fix in setCopyInheritanceSrc()
- re-usable helper method MethodBinding.getCodeGenType(int)
  - this helper also reverts substitution of mapping-level type variables
- apply the same strategy (from MethodBinding.signature()) consistently to all
  uses of MethodSpec, too, including especially CallinMethodMappingsAttribute.
Revert structure from r1143, which is superseded by the above strategy change:
- we no longer need to know where a mapping is inherited from, since we 
  will find the correct method using signature comparison

r1174,75: small regression fixes

r1176f: 
one more location needs to erase before comparing types,
witnessed by new test where a role inside a parameterized team has a callin
binding, enclosing type is a RawTypeBinding.

r1178f:
Several fixes for parameterized teams (inheritance w/o substitution, binary roles -  tests included):
- avoid wrapping the tsuper link, which caused StackOverflow because a
  WeakenedTypeBinding was recorded as its own superInterface
- avoid to create RawTypeBindings for generated AST by referring to role type
  via singleTypeReference in:
  - getClass and liftTo methods plus types of the role caches
Comment 6 Stephan Herrmann CLA 2010-12-14 19:08:06 EST
Additional improvements, mostly regarding incremental compilation:

r1180: 
Fix regression in test1125_outerAccessInNestedTeam3() by consolidating how the
synthetic arg for static role methods is weakened.

r1182:
make sure basecall surrogate is recognized when read from byte code 
(compare erasures).

r1184:
transfer a few modifier bits into a RoleTypeBinding in order to ensure proper
generation of generic signatures.
Without this incremental building regarded same generated methods (getClass..)
as name-clash.

With the exception of the special situation of bug 332582 working with
parameterized teams now works to satisfaction - as witnessed by the new
tests in suite Java5 and manual experiments regarding the SOM-cache example.
Comment 7 Stephan Herrmann CLA 2010-12-16 17:56:30 EST
Verified for M4 using build 201012150343