Bugzilla – Full Text Bug Listing
| Summary: | [compiler][generics] implicit inheritance must apply substitution for type variables from outer scope | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] Objectteams | Reporter: | Stephan Herrmann <stephan.herrmann> | ||||||
| Component: | OTJ | Assignee: | Stephan Herrmann <stephan.herrmann> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | ||||||||
| Version: | 0.8 | ||||||||
| Target Milestone: | 0.8 M4 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
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?)
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().
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. 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. 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 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. Verified for M4 using build 201012150343 |
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.