-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IrTypeparameter resolution #780
Conversation
container.allTypeParameters.withIndex().associate { | ||
it.value to getTypeArgument(it.index)!! | ||
} | ||
fun IrTypeParametersContainer.getTypeSubstitutionMap(expression: IrMemberAccessExpression): Map<IrTypeParameter, Either<KotlinType?, TypeProjection?>> = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I was also keen on return Map<IrTypeParameter, Either<IrSimpleType, IrTypeArgument>>, depending on how we use it in other places, besides Extensions.
But we can change it to one or the other, it's not fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you @i-walker looks good! 🙌
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏 thanks @i-walker !
addresses #749, as in adding new members and utilities to resolve IrTypeParameters through the IrTree and recursively walking the parent hierarchy for potentially unsubstituted type parameters.
Conceptually, it enables the functionality found in
IrTypeSubstituter
, which is specialized forIrValueParameters
forIrMemberAccessExpressions
, by breaking down its API and behavioral aspects.In a further PR, this can be used to refine the
targetType
, when extension proofs are injected, that have missing type information. But the technical debt persists to improve the detection of that verytargetType
consistently for all expressions.An example is here - given that List has an Functor instance:
List<T>
T
Int
B from fmap
B
Int
To further resolve
fmap
the remaining Type parameters in the parent hierarchy need to be resolved ofFunctor
andFunctor.Ops
, which is:Functor.Ops<F, A>
F
,A
F
->ListOf<Int>
,A
->Int
Functor<F>
F
ListOf<Int>
implying that
ListOf<A>
is an typealias forKind<
List(_), A>
and established as an isomorphism toList<T>
This is necessary, because the expected value- and target type for an extensionproof injection at the aforementioned call-site would be:
List<Int>
or worst case:List<T>
<- detection worksFunctor<F, A>
<- which can now be refined toFunctor<ListOf<Int>, Int>
But currently the target Type is not resolved to
Functor<F, A>