How do I use IrTypeSystemContext to figure out if ...

# compiler

[Alexander Ioffe]

How do I use IrTypeSystemContext to figure out if some function fun <T: SomethingIDontKnow> stuff(value: Foo<T>) is actually valid for some value Foo<SomethingElseIDontKnow>? Is there some way to typecheck the IrCall stuff(somethingIDontKnow) or compare the two IrType instances Foo<T> (from valueParamters[0] of stuff) and Foo<SomethingElseIDontKnow>? I tried using IrTypeSystem.Context.intersectTypes but that doesn't do the right thing.

[dmitriy.novozhilov]

What do you mean by SomethingIDontKnow?
You know all the types at IR level

[Alexander Ioffe]

Yeah, I know the IrType. I meant it’s a class created by the user.
(Since I’m sadly not a compiler-developer in my day job. For me, the term “unknown class” means a known supplied value for T.)

[Alexander Ioffe]

Bottom line, I’m trying to figure out if some IrType can be used as a parameter for a specific single-argument function (which may or may not have generics) or not.

[Javier]

@dmitriy.novozhilov I think this is similar to the feature request I asked for to detect if a type is compatible with another type as AbstractTypeChecker.isSubtypeOf was not covering that use case.

[Javier]

Related to the workaround I mentioned you about using Tower Resolver, etc.

[Alexander Ioffe]

@Javier What’s the workaround? Any chance you could point me to a thread?

[Javier]

It wasn’t in IR, it lives in the arrow context or arrow inject repositories

[Alexander Ioffe]

Looking now. What you're talking about is in the ProofResolutionStageRunner?

[Javier]

Yes

[Alexander Ioffe]

What is a ConeKotlinType ? NVM got that.

[Alexander Ioffe]

Any chance you could give me the cliff-notes on how createAndCompleteCandidate works?

[Javier]

Long time ago I don’t touch it, the only thing I remember is we needed to build some Call Info and get the type was applicable

[Alexander Ioffe]

That was the workaround?

[Javier]

We used that to detect if a type was compatible with another one, or in other words, if you are asking for a Proof, a specific type, check in the list of Proofs if someone was applicable.

[Alexander Ioffe]

Why was it needed? Where was the Kotlin type-system insufficient? Was it there to understand Kind<F, T> or something like that?

[Javier]

In order to allow injecting proofs with generics.

You can add a proof to the graph that could be Box<T>, and another proof that can be Foo. If you want to get the proof Box<Foo>, we needed to check if it was applicable with that approach

[Javier]

It was related to the fact you cannot check the exact type, because another compatible one could be

interface Foo

class Bar : Foo

provides -> Box<T>

provides -> Bar()

ask for -> Box<Foo>

As you are not asking for the exact same type, but it is indeed compatible because you the two compatible types in the graph, it must allow getting Box<Foo>. Without that, we can only compare exact same type, so Box<Bar> would work but Box<Foo> not.

[dmitriy.novozhilov]

I think this is similar to the feature request I asked for to detect if a type is compatible with another type as AbstractTypeChecker.isSubtypeOf was not covering that use case.

If we are talking about just checking the applicability of the single argument to the single parameter then isSubtypeOf is completely suitable. Just substitute the T in parameter with actual type argument.

But if we are talking about inferring T at IR level, then there is no such API. The compiler does the inference stuff at the fronted level